1.
Provision or retrieve the receiving details supported by the selected market.
2.
Present the bank account, payment key, QR code, or payment link to the payer.
3.
Receive a webhook when the incoming payment is confirmed.
4.
Use the returned orderId to query and reconcile the same PayIn order.
5.
Refund the payment when eligible, or use the available fiat balance in subsequent flows.
Persistent receiving details: Static PIX Key, CLABE, collection account, or Virtual Account.
Dynamic payment instructions: Dynamic QR Code or Dynamic Payment Link with a defined validity period.
Pooled collection: Shared Pool Account with an assigned reference code for transaction attribution.
A confirmed PayIn is notified as orderStatus=SUCCESS on the original VA* order.
Refund terminal events are notified on the RE* child (PAYIN_REFUND / PAYOUT_REFUND).
Use orderId as the unique identifier for tracking the order being notified.
Process webhook events idempotently.
Use the order query API as a fallback when verification is required. Do not infer refund success from timeout.
BPN creates a separate RE* child (businessType PAYIN_REFUND or PAYOUT_REFUND).
The original VA* order orderStatus stays SUCCESS. Use refundStatus / refundOrderId on the original, and originalOrderId on the child.
Track the child: orderStatus=PROCESSING + refundStatus=REFUNDING → REFUNDED+REFUNDED or FAIL+REFUND_FAILED.
Webhook terminal refund events are on the RE* child, not original-order orderStatus=REFUNDED.
Timeout or missing callback must not be treated as success.
Use a unique request identifier when creating resources or initiating transactions.
Use orderId as the primary identifier for PayIn tracking.
Verify webhook signatures before processing events.
Process repeated webhook events idempotently.
Use active order queries when a webhook is delayed or additional verification is required.
Do not assume that account type, required fields, limits, or refund support are identical across markets.