Skip to main content
Sending a Pix is a flow of separate steps. You create the payment, which resolves who you’re paying and the amount; you set its details if any are missing; then you confirm it, and only then the money moves. If your organization’s business policies require approval for the payment, you send it for approval instead of confirming it — see Business policies and approvals.

Flow

Step 1: Create the payment

Identify the recipient by a Pix key, a Pix Copia e Cola / QR code, or the recipient’s bank details.
The payment is created as REQUESTED — nothing is paid yet. Review who you’re paying (creditParty) and how much (txnUpdatedAmount) before going on:
Keep the payment’s _id — it is the {pixId} of every next step. pendingConfirmation holds what will be paid, and policy what your organization’s business policies say about it. Reference: Create a Pix payment

Step 2: Set the details, if any are missing

Confirming pays exactly what pendingConfirmation holds, so it needs the amount and the balance category. If you sent both at creation, skip this step. Otherwise — a QR code, or a create without category — set them:
Unless the QR code has an open amount, amount must be the payment’s txnUpdatedAmount (a COBV charge scheduled for its due date may also pay its txnOriginalAmount). The answer carries an updated policy. Reference: Set a Pix payment’s details

Step 3: Confirm the payment

When policy.actions.autoAction is APPROVE, confirm the payment — with no body:
A successful confirmation answers 200 with the payment CONFIRMED; it becomes PAID when the Pix network settles it, and receipt.endToEndId is the ID the recipient’s bank shows. If the payment is refused — for insufficient funds or a limit, for example — it becomes FAILED, with the reason in failReason, and you get the error. When autoAction is NONE, the payment needs approval: send it for approval instead of confirming it. With DENY, the policies refuse it. Reference: Confirm a Pix payment

Pay on a later day

Send scheduledAt (YYYY-MM-DD) when creating the payment, or with PUT, to pay on a later day. The confirmation then answers 201 with the schedule, and the payment becomes SCHEDULED; on that day a new payment is created and paid. The day’s payment doesn’t carry the custom fields: in an organization with a required transaction custom field, it fails. A QR code charge with a due date can only be paid today or on its due date, and only payments by Pix key or QR code can be scheduled — a payment by bank details for a later day is refused at confirmation.

Cancel a payment

A payment that wasn’t paid yet — REQUESTED, waiting for approval, or SCHEDULED — can be cancelled:

Next steps

Business policies and approvals

Send payments for approval when your organization’s policies require it.

Charge with PIX

Generate a QR Code to receive money instead of sending it.