QR Payments overview

QR Payments let you initiate local payment network transactions—Yape, Plin, PIX, QR 3.0, BREB, and others—through a single API integration. The payer's funds are debited in the configured currency and settled to the destination account via the country's domestic payment rail.

sender is required on every lock request and identifies the real payer for compliance. In the End-user model, sender matches the user identified by userAnyId. In the Principal Accounts model, userAnyId identifies your principal account while sender carries the end-user identity. See Onboarding models.

Payment flow

1. Lock — POST /v2/payment-locks to validate the destination and reserve payment context. Returns a code.
2. Execute — POST /v2/synthetics/qr-payment using the code as paymentCode.
3. Track — Receive SYNTHETIC_STATUS_UPDATE webhooks or poll GET /v2/synthetics/{syntheticAnyId}.

Refund support

Refund cases are exposed through synthetic lifecycle data and PAYMENT_REFUND events. Partial refunds can happen more than once and keep the synthetic COMPLETED; only a fully refunded outcome moves it to CANCELLED. Use reconciliation endpoints to classify internal reversals vs external refunds.

See also

• Preview a payment — lock request details and sender requirements
• Make a payment — execution request and response
• Payment lifecycle — status transitions and webhook payloads
• After the payment — webhook payloads and refund handling
• Error handling — lock and execution error codes