Obtain JWT tokens to authenticate all other requests.
ConnectPSP API (2.2.0)
ConnectPSP is a PIX payment gateway designed for high-throughput platforms such as digital wallets, betting companies, and fintechs.
This API allows you to:
- 💸 Receive payments via PIX (Cash-In) — standard QR Code or OpenFinance
- 🏦 Send payments via PIX key or bank account data (Cash-Out)
- 📊 Manage your wallet — check consolidated balances and rebalance between transactional and proprietary accounts
- 🪝 Receive real-time events via Webhooks as transactions progress
All endpoints (except POST /auth/token) require two headers:
| Header | Description |
|---|---|
Authorization | Bearer <jwt_token> — obtained from POST /auth/token |
ApplicationToken | Fixed GUID token that identifies your integration |
For financial operations (Cash-Out, Rebalance), an additional header is required:
| Header | Description |
|---|---|
DigitalSignature | HMAC-SHA256 hash of your JWT + CryptoToken. See Authentication Guide |
X-Idempotency-Key is optional on POST /cash-in and POST /cash-out, and recommended (a UUID v4 per operation). With it, a network retry returns the original response instead of creating a second transaction. Without it, the request is processed normally and externalReference still blocks duplicates with 409 DUPLICATED_EXTERNAL_REFERENCE. See the Authentication Guide for the full rules.
| Phase | What to confirm first |
|---|---|
| Setup | Credentials, environment, headers, and webhook readiness in Initial Setup |
| Authentication | JWT generation and DigitalSignature rules in the Authentication Guide |
| Transactions | Your first Cash-In or Cash-Out flow with idempotency and webhook validation |
Request
Aggregated Cash-In figures for a period: totals per status, and the same figures broken down by settlement bank.
Use this instead of walking the whole list when you only need the numbers.
| Key | Meaning |
|---|---|
pending | Not paid — covers both awaiting payment and expired |
paid | Settled |
refunded | Returned to the payer |
⚠️ There is no
expiredbucket. Expiry depends on the charge's due date, which the aggregate does not read, so expired charges are counted underpending. The listing endpoint does distinguish them per item.
A bucket only appears when it has at least one transaction.
settlement counts and sums paid transactions only. Money that has not settled is not attributed to any bank — this is what makes the figures reconcile against GET /account/balance.
Start of the period, inclusive. Accepts a plain date (YYYY-MM-DD) or a full ISO 8601 timestamp (YYYY-MM-DDTHH:mm:ss).
Times without an explicit offset are read as America/Sao_Paulo (UTC-3). A plain date becomes 00:00:00.000 of that day in that timezone.
The period filters on when the transaction was created, not when it was paid.
- Staging Environment (Testing)https://api.homologacao.connectpsp.com/cash-in/summary
- cURL
- JavaScript
- Node.js
- Python
- Java
- C#
- PHP
- Go
- Ruby
- R
- Payload
curl "https://api.homologacao.connectpsp.com/cash-in/summary?from=2026-08-01&to=2026-08-01" \
-H "Authorization: Bearer <token>" \
-H "ApplicationToken: <app-token>"Aggregated figures for the period.
Start of the period, echoed back in America/Sao_Paulo.
Status key → {count, amount}. Only statuses with at least one transaction appear.
Cash-In keys: pending, paid, refunded. Cash-Out keys: the Cash-Out statuses in lowercase — processing, pending, completed, cancelled, refunded.
Breakdown by settlement bank, paid transactions only (paid on Cash-In, completed on Cash-Out), ordered by amount descending.
{ "from": "2026-08-01T00:00:00-03:00", "to": "2026-08-01T23:59:59-03:00", "currency": "BRL", "totals": { "paid": { … }, "pending": { … }, "refunded": { … } }, "settlement": [ { … }, { … } ] }
Request
Returns the current status and details of a Cash-In transaction.
The body is the same object delivered in the data of the CASHIN_* webhooks — see the Webhooks guide for the single documented difference on refunds.
The {id} parameter accepts any of the identifiers below. When a value matches more than one transaction, the result is deterministic: the first level in this order wins, and within the same level the most recent transaction wins.
| Order | Identifier |
|---|---|
| 1 | internalCode (e.g. US7B1JQ) |
| 2 | transactionId (TxId) |
| 3 | endToEndId of the payment (starts with E) |
| 4 | endToEndId of the refund (starts with D) |
| 5 | externalReference (your own reference) |
Prefer internalCode: it is the only identifier that can never collide with another level.
When status is REFUNDED, reason tells you why the money went back to the payer:
reason | Meaning |
|---|---|
FRAUD | Refunded because of fraud, including a MED (Special Return Mechanism) claim |
DUPLICATED_PAYMENT | You requested the refund with this reason |
CUSTOMER_REQUEST | Refund at the customer's request — the reason you sent, or a devolution the bank flagged as requested by the customer |
MERCHANT_ERROR | You requested the refund with this reason |
PAYER_NOT_ALLOWED | Refunded automatically because the payer is not allowed to pay you |
OTHER | Any other reason |
- Staging Environment (Testing)https://api.homologacao.connectpsp.com/cash-in/{id}
- cURL
- JavaScript
- Node.js
- Python
- Java
- C#
- PHP
- Go
- Ruby
- R
- Payload
curl https://api.homologacao.connectpsp.com/cash-in/US7B1JQ \
-H "Authorization: Bearer <token>" \
-H "ApplicationToken: <app-token>"Cash-In details returned successfully.
End-to-end ID issued by BACEN/SPI upon settlement.
- For paid transactions: starts with
E(e.g.E00416968...) - For refunded transactions: starts with
D(Devolution)
The original E2E ID when endToEndId represents a refund.
AWAITING_PAYMENT— created, not paid yetPAID— payment confirmedEXPIRED— expired without payment; seeexpiredAtREFUNDED— paid, then returned to the payer; seereasonandrefundedAtCANCELLED— cancelled before being paid; seecancelledAt
Why a paid Cash-In went back to the payer. Present only when status is REFUNDED.
FRAUD,DUPLICATED_PAYMENT,CUSTOMER_REQUEST,MERCHANT_ERROR— the reason you sent onPOST /cash-in/{id}/refund.FRAUDalso covers a MED (Special Return Mechanism) claim, andCUSTOMER_REQUESTa devolution the bank flagged as requested by the customerPAYER_NOT_ALLOWED— refunded automatically because the payer is not allowed to pay youOTHER— any other reason
Banking details returned after settlement. May be null before settlement.
Present only when money actually moved: PAID and REFUNDED. Absent in AWAITING_PAYMENT, EXPIRED and CANCELLED — no ConnectPSP account received anything.
When the charge was created. Always present, in every status.
- paid
- refunded
{ "transactionId": "kk6g232xel65a0daee4dd13kk2912714964", "internalCode": "US7B1JQ", "externalReference": "order_abc123", "endToEndId": "E00416968202603101827cemeFscF6AG", "status": "PAID", "amount": 150.5, "payer": { "name": "João Silva", "document": "12345678909", "bankData": { … } }, "settlement": { "ispb": "12345678", "bank": "SETTLEMENT PARTNER A", "branch": "0001", "account": "123456" }, "requestedAt": "2026-03-10T11:20:00-03:00", "paidAt": "2026-03-10T11:22:15-03:00" }
Request
Requests a full refund of a paid Cash-In transaction (PIX Devolution via BACEN/SPI).
⚠️ Important: Only transactions with status
PAIDcan be refunded. Partial refunds are not supported — the full original amount will be returned to the payer.
The refund is sent to the banking network synchronously. The 202 Accepted response includes the new endToEndId generated for the devolution (prefixed with D).
This endpoint requires the DigitalSignature header. See the Authentication Guide for details on how to compute it.
Fixed GUID that uniquely identifies your integration. Provided during ConnectPSP onboarding.
HMAC-SHA256 hash of the JWT token + your CryptoToken. Required for sensitive operations. See the Authentication Guide for the exact computation steps.
Reason for the refund. It comes back as reason on GET /cash-in/{id} and on CASHIN_REFUNDED.
- Staging Environment (Testing)https://api.homologacao.connectpsp.com/cash-in/{id}/refund
- cURL
- JavaScript
- Node.js
- Python
- Java
- C#
- PHP
- Go
- Ruby
- R
- Payload
curl -X POST https://api.homologacao.connectpsp.com/cash-in/US7B1JQ/refund \
-H "Authorization: Bearer <token>" \
-H "ApplicationToken: <app-token>" \
-H "DigitalSignature: <computed-signature>" \
-H "Content-Type: application/json" \
-d '{
"reason": "CUSTOMER_REQUEST",
"description": "Customer requested refund via support ticket #1234."
}'{ "transactionId": "kk6g232xel65a0daee4dd13kk2912714964", "internalCode": "US7B1JQ", "externalReference": "order_abc123", "endToEndId": "D00416968202603101827cemeFscF6AG", "status": "PROCESSING", "amount": 150.5, "requestedAt": "2026-03-10T13:30:00-03:00", "message": "The refund for cash-in US7B1JQ has been successfully initiated." }
PIX Health tells you whether PIX is working for you right now, and who is at fault when it is not.
A statistical engine compares every 5-minute window of your PIX traffic with what is normal for that weekday and time over the last four weeks, and attributes any clear deviation to the platform, to a settlement partner, to a payer bank or to your own operation — always scoped to what you actually use.
Three endpoints, all read-only and all safe to poll once a minute:
| Endpoint | Use it for |
|---|---|
GET /health/pix | The picture of the moment: status per block plus the incidents open right now |
GET /health/pix/incidents | History of confirmed incidents, paginated |
GET /health/pix/incidents/{id} | One incident with the evidence behind the verdict |
None of them require DigitalSignature or X-Idempotency-Key — only Authorization and ApplicationToken.
Confirmed incidents are also pushed as webhooks (PIX_INCIDENT_DETECTED / UPDATED / RESOLVED), so you do not have to poll to be warned; see the Webhooks guide.