v2.63.0 — Administrator partner checked at PJ POST time

POST /v1/accreditations/pj now requires exactly one partner with partners[].isAdministrator: true. The banking provider accepts a single administrator per company and only said so afterwards — with the biometrics links already issued, every partner already through facial recognition and the company PDFs already uploaded. More than one administrator is now refused upfront with 400 invalid_field, naming partners[].isAdministrator and the flagged indexes. No link is issued and no journey is spent.
The number of partners did not change. The limit counts administrators: a company with several partners and a single administrator keeps going through.
No administrator at all is still refused with 400 invalid_payload, as before.
GET /v1/accreditations/{id} now returns the partner block on refusals coming from the banking provider — the same one already delivered in the accreditation.failed webhook. Until now the query showed less than the webhook. The field is omitted when there is no provider refusal.
Two fixes in the error documentation. The reason field is called errorReason (the table said reason), and the partner block mirrors what the provider sent: code, message and field are all optional, and some refusals arrive with message only — in those the field is not named.

Attention / action required

If you build partners[] flagging every partner as an administrator, the call now answers 400 instead of being accepted and failing hours later. Flag only the company’s administrator and send the others with isAdministrator: false.

v2.64.0 — PIX out held at the settlement bank: who is holding it, and the late outcome

hold tells you whose court the ball is in. The payment lookup (GET /v1/accounts/{accountId}/pix/payments/lookup) and the pix.out.timeout webhook now carry hold, with owner: "partner" and reason (partner_authorization, partner_risk_analysis or partner_unspecified), whenever the order is held at the settlement bank. When that object is present, there is nothing to approve on your side or on ours.
partnerStatus and partnerStatusId carry the raw state at the settlement bank, useful to attach to a support ticket. They are its values, outside our canonical vocabulary: do not use them in status comparisons.
status did not change. PENDING_APPROVAL keeps the exact same value — no integration that compares status strings needs to change. The field is ambiguous by birth (it covers both the settlement bank’s internal authorisation queue and its risk review) and will be split in a future major version; until then, hold is the answer to “who needs to act”.
TIMEOUT is no longer the end of the road. While an order is held, we keep polling the settlement bank for up to 7 days. If it settles or rejects within that window, you receive pix.out.completed or pix.out.failed with late: true and the same paymentId as the earlier pix.out.timeout — it corrects that outcome, it is not a second payment. Before, a late release could simply never reach you.
The late event duplicates nothing. Its event identifier is the payment’s, so a late confirmation and our reconciliation converge on a single terminal event per order.
The timeline deadline message now states the real deadline. The pix_out.timeout event said “5-minute deadline” even when the wait had been 25 minutes, and never mentioned that the order was held at the settlement bank.

Heads-up / action required

If your system treats pix.out.timeout as a final outcome, adjust it to accept a later pix.out.completed / pix.out.failed with the same paymentId (identify it by late: true). Reprocessing the payment in that case would send the money twice.