Comprovante do pagamento
/v1/payments/{id}/receiptEmite o comprovante de PIX, boleto ou cartão, com pagador mascarado. PDF renderizado a cada chamada, sem cache; URL pré-assinada de 15 min. Throttle próprio: 5 req/s (burst 10).
X-Merchant-Id é obrigatório com credencial de organização; com credencial de merchant é opcional (ausente = o próprio merchant).
AuthorizationBearer <token>Token obtido no Zitadel do ambiente (POST /oauth/v2/token), fora do host da API, e enviado em Authorization: Bearer <access_token>.
- Sandbox:
https://kodano-uat-p55zt6.us1.zitadel.cloud/oauth/v2/token - Produção:
https://kodano-prod-qe8hbt.us1.zitadel.cloud/oauth/v2/token
Use sempre o tokenUrl devolvido na emissão da credencial. Duas variantes: private_key_jwt (preferida; grant urn:ietf:params:oauth:grant-type:jwt-bearer com assertion RS256 assinada pela chave da credencial, iss = sub = userId, aud = authority do Zitadel, kid = keyId) e client_secret (grant client_credentials). O OpenAPI só modela a segunda.
O parâmetro scope do token é OIDC, não os escopos da API: openid urn:zitadel:iam:org:project:id:<projectId da API>:aud urn:zitadel:iam:user:resourceowner. Sem o :aud a API responde 401 AUTH.TOKEN_INVALID; sem resourceowner, 403 AUTH.TENANT_MISMATCH.
Os 28 escopos abaixo são os entitlements concedidos à credencial pelos produtos de integração (produto:recurso:ação; write não implica read), avaliados a cada requisição; não são pedidos no token. O tenant vem da organização do token; o merchant, de X-Merchant-Id. Revogar a credencial nega os tokens já emitidos em até 60 s.
Scope: payments:pix:read
id*stringId do pagamento (pay_…). Malformado → 404.
X-Merchant-Id*stringMerchant da operação (mrc_ + Guid sem hífens, minúsculo). Obrigatório com credencial de organização (ausente → 400 MERCHANT.HEADER_REQUIRED); com credencial de merchant é opcional (ausente = o próprio merchant). Malformado, repetido, inexistente ou de outro tenant → 403 MERCHANT.FORBIDDEN (nunca 404). Vazio = ausente.
^mrc_[0-9a-f]{32}$X-Correlation-Id?stringOpcional, sempre ecoado na resposta e repetido em correlationId do Problem. Ausente ou inválido → o serviço gera UUID v7.
^[A-Za-z0-9._-]{1,64}$Comprovante. Com Accept: application/json (ou ausente) vem o JSON com URL pré-assinada do PDF (pdf: null onde não há bucket, como no sandbox); com Accept: application/pdf vem o PDF direto com Content-Disposition: attachment.
- response
paymentId*string^pay_status*PaymentStatusNove status mutuamente exclusivos. Precedência entre os derivados de sucesso: CHARGEBACK > REFUNDED > PARTIALLY_REFUNDED > CAPTURED/SUCCEEDED > AUTHORIZED.
"PENDING""AUTHORIZED""CAPTURED""SUCCEEDED""FAILED""CANCELED""REFUNDED""PARTIALLY_REFUNDED""CHARGEBACK"paidAt*stringdate-timeamount*integercurrency*"BRL"Único valor na v1.
"BRL"refundedAmount*integermethod*PaymentMethod"PIX""BOLETO""CARD"card?Só em cartão; bloco de PIX e boleto não definido no TDD.
payer*pdf*|nullcurl -X GET 'https://api.sandbox.kodano.com.br/v1/payments/string/receipt' \ -H 'X-Merchant-Id: mrc_0f8fad5bd9cb469fa16570867728950e' \ -H 'X-Correlation-Id: erp-7f3a-0010'{ "paymentId": "pay_Lq7Tz2WcR9hN4bVx1sKe6pYd3MfA", "status": "PARTIALLY_REFUNDED", "paidAt": "2026-10-15T18:00:01Z", "amount": 25000, "currency": "BRL", "refundedAmount": 5000, "method": "CARD", "card": { "brand": "VISA", "last4": "4242" }, "payer": { "name": "Loja XYZ Ltda", "document": "**.***.678/0001-**" }, "pdf": { "url": "https://files.kodano.com.br/receipts/pay_Lq7Tz2WcR9hN4bVx1sKe6pYd3MfA.pdf?expires=900&signature=...", "expiresAt": "2026-10-16T13:15:00Z" }}