Certification checklist

The formal acceptance criteria for production access. Work through every item and confirm it against your own implementation — each links to the guide that explains it.

Validating this checklist is the third gate before credentials are released. Once it is accepted, follow Production access.

There are 27 items across six areas.

Authentication and connectivity

#	Criterion	Guide
1	OAuth 2.0 flow — access tokens are generated from client_id and client_secret	Authentication
2	Token management — tokens renew automatically before the 2-hour expiry	Authentication
3	mTLS — certificates generated and tested successfully	mTLS Onboarding

Deposits (Pix-In)

#	Criterion	Guide
4	QR Code generation — immediate charges are created successfully	Deposits
5	Metadata — the player id or internal transaction id is sent in externalId or metadata for reconciliation	Deposits
6	Expiration — the EXPIRED status is handled when the player does not pay in time	Deposits
7	Payment simulation — /v1/pix/mock/simulate-payment was used to validate the credit path	Quickstart
8	Multiple attempts — a FAILED payment does not cancel the QR Code; repeated attempts against one charge are handled	Deposits
9	Ownership — the rejection scenario was tested when the payer CPF differs from the player CPF (IGAMING_CPF_MISMATCH)	Ownership rules

Withdrawals (Pix-Out)

The most critical area for iGaming.

#	Criterion	Guide
10	PIX key withdrawal — sending to CPF, e-mail and phone keys was validated	Withdrawals
11	Manual withdrawal — sending via ISPB + branch + account was validated	Withdrawals
12	Idempotency — resending the same externalId after a network error returns the original transaction instead of paying twice	Idempotency
13	Ownership — the rejection scenario was tested when the receiver CPF differs from the player CPF	Ownership rules
14	Statuses — the request → processing → final status flow is understood and implemented	Status Machine — Pix Out

Webhooks and notifications

#	Criterion	Guide
15	Configuration — the webhook endpoint was configured and validated	Webhooks overview
16	Security — authentication (Bearer/Basic) of incoming notifications is validated	Webhooks overview
17	pixChargePaid — the player balance is credited immediately after this event	Events
18	pixWithdrawFailed — balance is returned to the player wallet when a withdrawal is returned by the destination bank	Withdrawals
19	Webhook idempotency — duplicate notifications with the same endToEndId are ignored	Credit exactly once

Reconciliation and financials

#	Criterion	Guide
20	Balance inquiry — /v1/balance/realtime is queried to validate cash flow	Balance
21	Detailed statement — specific transactions are fetched via GET /v1/statement using the endToEndId	Statement
22	Refunds — refunding a received PIX was tested for fraud or error scenarios	Refunds

Error handling and edge cases

#	Criterion	Guide
23	Timeouts — network timeouts are not treated as definitive failures; a subsequent GET confirms the status	Retries and timeouts
24	Insufficient balance — the error response is handled when the merchant balance is below the requested amount	Balance
25	Contingency polling — a sweeping job queries old PENDING or INITIATED transactions in case the webhook fails	Contingency polling
26	ID mapping — the endToEndId of every transaction is stored	Glossary
27	Error 500 — a 500 returned directly in the response is treated as a confirmed failure and the transaction is closed as failed	Retries and timeouts

Cross-cutting requirements

Beyond the numbered items, homologation also reviews:

• Credential segregation between staging and production, with documented rotation — Environments

• Webhook response time under 5 seconds, with events queued before processing — Webhooks overview

• externalId unique per operation (UUID v4 recommended, 100 characters maximum), persisted before sending, reused across retries of the same operation — Idempotency

• Amounts handled as integer cents end to end, never as decimals — Glossary

• No action taken on transitional statuses (INITIATED, PENDING, PROCESSING) — Status Machine

• 422 treated as definitive, with no automatic retries — Errors

• expiresIn aligned with the interface countdown, at least 600 s — Deposits

• Refund control via leftAmount and canBeReversedUntil — Refunds

• Withdrawals are never cancelled without a GET confirming the current status — Critical warnings

• A payment error does not close the charge: pixChargeRejected arrives with a non-final status and the system keeps waiting for pixChargePaid or pixChargeExpired — Deposits

Next

When every item is satisfied, request production access — Production access.