Go-live checklist
1
Full flow validated in the sandbox
Create charge → receive
transaction.paid webhook → release the order. Also test the unhappy paths: expiration (transaction.expired) and cancellation. In the sandbox you can simulate them all.2
Webhook signature verified
Does your application reject webhooks with an invalid signature? Test it by sending a forged POST to your endpoint. Use the SDK or the verification examples — always with the raw body. New channels use the v2 format (anti-replay).
3
Idempotent webhook consumption
Deliveries may repeat (platform retry). Processing the same
transaction.paid twice must not release the order twice — deduplicate by transactionId.4
Creation with Idempotency-Key
A timeout on creation must not turn into a duplicate payment. Send
Idempotency-Key (the SDK does it for you) and retry with the same key after network failures.5
HTTP 202 handled
In rare degradation, creation responds with
202 and id: null — the PIX is valid, deliver it to the buyer and use externalId as the reference. See Errors.6
Errors handled by code, not by message
Handle by
status + type and retry transient errors with backoff. The errors page tells you what to do with each one.7
Swap the key
Replace
sk_test_* with sk_live_* in your environment variables. That’s it — same API, same endpoints.Sandbox and production transactions are fully isolated — nothing you created with
sk_test_ shows up in the project’s real numbers.Next steps
Configure webhooks
Confirm each payment by the event, not by the creation response.
Idempotency
Retry creation requests without the risk of charging twice.