# Histórico de alterações Esta página resume as alterações relevantes feitas no Payments Direct. O histórico está ordenado da alteração mais recente para a mais antiga e corresponde ao mês e ao ano em que as melhorias e as correções foram disponibilizadas. ### Setembro de 2026 details summary Clique para expandir **O Japão (JPY) está disponível novamente** O corredor do Japão (JPY), `JP_ZENGIN`, foi restaurado na documentação e na especificação da API depois de ter sido retirado no início de setembro de 2026. `financialInstrumentType` e `validatePayoutRails` voltam a aceitá-lo, e o schema de payload, a página de requisitos de dados e a consulta de códigos bancários estão publicados. A página agora lista todos os requisitos de dados do corredor: as identidades do beneficiário e do ordenante, o instrumento financeiro do beneficiário e a própria transação. Consulte a [página de requisitos de dados do Japão (JPY)](/pt-br/products/payments-direct-2/api-docs/integration-resources/apac/jp/jpy). Os demais corredores retirados em setembro de 2026 continuam indisponíveis. **Documentos de identidade obrigatórios para organizações na jurisdição do Brasil (BR)** Se a sua organização estiver configurada para a jurisdição do Brasil (BR), `identityDocuments` passa a ser obrigatório em toda identidade ORIGINATOR, em todos os corredores, inclusive naqueles que de outra forma não o exigiriam. Omiti-lo faz a criação e a atualização de identidades falharem com **400 Bad Request** (`USR_111`). A jurisdição é uma propriedade da sua organização que a Ripple registra na sua conta. Não é um valor que você envia em uma requisição e independe dos corredores indicados em `validatePayoutRails`. A regra vale tanto para atualizações quanto para criações. Uma atualização valida o corpo que você envia, não o registro já armazenado, portanto uma atualização que omita `identityDocuments` falha mesmo ao alterar algo não relacionado. Identidades criadas antes desta mudança também são afetadas. Identidades de ordenante do tipo empresa não são afetadas, porque identidades de empresa não têm `identityDocuments`. Consulte [Requisitos por jurisdição](/pt-br/products/payments-direct-2/introduction/concepts/payment-identities#requisitos-por-jurisdi%C3%A7%C3%A3o). **A Tailândia (THB) está disponível novamente** O corredor da Tailândia (THB), `TH_PROMPTPAY`, foi restaurado na documentação e na especificação da API depois de retirado no início de setembro de 2026. `financialInstrumentType` e `validatePayoutRails` voltam a aceitar `TH_PROMPTPAY`, e o schema de payload, a página de requisitos de dados de transação e a consulta de códigos bancários estão publicados. Consulte a [página de requisitos de dados de transação da Tailândia (THB)](/pt-br/products/payments-direct-2/api-docs/integration-resources/apac/th/thb) para ver os campos, os valores válidos e as regras de validação deste corredor. **A China (USD) está disponível novamente** O corredor da China (USD), `CN_CFXPS`, foi restaurado na documentação e na especificação da API API depois de ter sido retirado no início de setembro de 2026. `financialInstrumentType` e `validatePayoutRails` voltam a aceitar `CN_CFXPS`, e o schema de payload, a página de requisitos requisitos de dados de transação e a consulta de códigos bancários estão publicados. `originatorAccountNumber` é obrigatório em identidades ORIGINATOR validadas em relação a `CN_CFXPS`. Consulte [O número de conta do ordenante](/pt-br/products/payments-direct-2/introduction/concepts/payment-identities#o-n%C3%BAmero-de-conta-do-ordenante). Analise as limitações conhecidas na [página de requisitos de dados de transação da China (USD)](/pt-br/products/payments-direct-2/api-docs/integration-resources/apac/cn/usd) antes de enviar neste corredor, e teste com um pagamento de baixo valor antes de aumentar o volume. **Consulta de códigos bancários: mais países e nomes de bancos em maiúsculas** A consulta [Códigos bancários](/pt-br/products/payments-direct-2/api-docs/integration-resources/ripple-bank-codes) agora cobre Japão, Tailândia, China (CNY), Indonésia, Singapura e Vietnã, além dos países que já atendia. Japão e Tailândia são corredores disponíveis. Os demais são publicados como referência antes dos respectivos corredores: `CN_BANK_PAYOUT`, `ID_BIFAST` e os payment rails de Singapura e do Vietnã não são valores aceitos atualmente em `financialInstrumentType` nem em `validatePayoutRails`. Singapura lista códigos SWIFT/BIC e o Vietnã lista Ripple Bank Codes. Os nomes dos bancos agora são exibidos em maiúsculas em todos os países; antes havia uma mistura de maiúsculas e inicial maiúscula. **Corredores não mais disponíveis nesta versão** Os corredores a seguir foram removidos da documentação e da especificação da API: - China (CNY), `CN_BANK_PAYOUT` - China (USD), `CN_CFXPS` (**restaurado posteriormente em setembro de 2026, veja acima**) - Hong Kong (HKD), `HK_BANK_PAYOUT` - Indonésia (IDR), `ID_BIFAST` - Japão (JPY), `JP_ZENGIN` (**restaurado posteriormente em setembro de 2026, veja acima**) - Filipinas (PHP), `PH_NRPS` - Tailândia (THB), `TH_PROMPTPAY` (**restaurado posteriormente em setembro de 2026, veja acima**) - Turquia (TRY), `TR_FAST` - Malásia (MYR), Singapura (SGD) e Vietnã (VND), que tinham requisitos de dados de transação, mas nenhum tipo de instrumento financeiro No momento desta mudança, esses oito tipos de instrumento financeiro deixaram de ser valores aceitos em `financialInstrumentType` e `validatePayoutRails`, e os respectivos schemas de payload e conjuntos de códigos bancários foram removidos, deixando `financialInstrumentType` com 25 valores. China (USD), Tailândia (THB) e Japão (JPY) foram restaurados desde então, portanto cinco continuam indisponíveis e `financialInstrumentType` agora aceita 28 valores. Algumas consultas de códigos bancários estão publicadas para corredores que continuam indisponíveis, conforme descrito acima. `originatorAccountNumber` era opcional em todos os corredores disponíveis no momento desta mudança. Ele voltou a ser obrigatório em identidades ORIGINATOR no `CN_CFXPS` quando a China (USD) foi restaurada. Continua disponível em identidades ORIGINATOR, mantém a regra de unicidade entre todas as identidades ativas e segue sendo encaminhado ao parceiro pagador quando você o envia. As entradas mais abaixo nesta página que anunciaram esses corredores são mantidas como registro do que foi publicado na época. **A busca de pagamentos por apelido do beneficiário agora é feita pelo serviço de identidades** Ao filtrar pagamentos com `beneficiaryIdentityNickname`, o apelido passa a ser comparado pelo serviço de identidades, e não com uma cópia mantida pelo serviço de pagamentos. Disso decorrem duas coisas: - Se um apelido corresponder a mais de uma identidade de beneficiário, a resposta inclui os pagamentos de todas as identidades correspondentes. Antes, a comparação era feita com um único valor armazenado por pagamento. - A correspondência segue a semântica do próprio serviço de identidades, portanto os resultados podem diferir do comportamento de substring que você via antes. Para selecionar beneficiários específicos, filtre por `beneficiaryIdentityIds`. Consulte [Criar e gerenciar identidades](/pt-br/products/payments-direct-2/api-docs/developer-guides/create-and-manage-identities) para descobrir a identidade por trás de um apelido. **Os apelidos nas respostas de pagamento refletem a versão da identidade referenciada pelo pagamento** `originatorIdentityNickName` e `beneficiaryIdentityNickName` nas respostas de pagamento retornam o apelido como ele estava na versão da identidade referenciada pelo pagamento. Editar um apelido depois não altera o valor retornado para um pagamento existente. **Apelidos mais longos aceitos nos campos de pagamento** O comprimento máximo de `originatorIdentityNickName`, `beneficiaryIdentityNickName` e do filtro de busca `beneficiaryIdentityNickname` aumentou de 100 para 256 caracteres. A mudança é aditiva: os valores existentes não são afetados. **Requisitos de dados reduzidos: corredores africanos** Vários campos de identidade deixaram de ser obrigatórios para `NG_BANK_PAYOUT`, `GH_BANK_PAYOUT`, `RW_BANK_PAYOUT`, `UG_BANK_PAYOUT`, `ZA_BANK_PAYOUT` e `ZM_BANK_PAYOUT`: - `citizenship` e `gender` — não são mais obrigatórios para identidades INDIVIDUAL BENEFICIARY - `identityDocuments` — não é mais obrigatório nas identidades INDIVIDUAL BENEFICIARY - `countryOfBirth` — não é mais obrigatório para identidades INDIVIDUAL ORIGINATOR - `registration` — não é mais obrigatório para identidades BUSINESS ORIGINATOR ou BUSINESS BENEFICIARY **`address.stateOrProvince` e `address.postalCode` agora são obrigatórios conforme o corredor** Antes, ambos os campos eram obrigatórios em todas as identidades. Agora são obrigatórios apenas nos corredores que precisam deles, o que exclui os corredores africanos listados acima. Se hoje você os envia em todos os casos, nada muda. **Os corredores africanos aceitam o Ripple Bank Code** `bankCode` em `NG_BANK_PAYOUT`, `GH_BANK_PAYOUT`, `RW_BANK_PAYOUT`, `UG_BANK_PAYOUT`, `ZA_BANK_PAYOUT` e `ZM_BANK_PAYOUT` agora aceita o formato Ripple Bank Code (RBC), por exemplo `RPL:NG:GTBINGLA:BNK`. Use a [consulta de códigos bancários](/pt-br/products/payments-direct-2/api-docs/integration-resources/ripple-bank-codes) para encontrá-lo. **Novos tipos de documento de identidade para pagamentos em CNY à China** `CN_BANK_PAYOUT` agora aceita mais dois valores de `identityDocuments.idType`: `HKID` e `HMTP` para identidades INDIVIDUAL ORIGINATOR, e `HMTP` para identidades INDIVIDUAL BENEFICIARY. **Requisitos de dados reduzidos: registro empresarial em payouts em USD à China e em cripto** `registration` não é mais obrigatório em identidades BUSINESS BENEFICIARY para os seguintes tipos de instrumento financeiro: - `CN_CFXPS` (pagamentos em USD à China) - `ETH_WALLET`, `TRON_WALLET`, `SOL_WALLET` (payouts em cripto) `registration` continua obrigatório em identidades BUSINESS ORIGINATOR para `CN_CFXPS` e permanece inalterado nos demais corredores. Onde você o envia, os valores aceitos em `registration.type` não mudaram. Nenhuma ação é necessária se você já envia `registration`. Para ver os campos obrigatórios atuais por corredor e papel, use o [Utilitário de schema de payload](/pt-br/products/payments-direct-2/api-docs/integration-resources/payload-schema-utility). **Nova documentação: cadastro de contas bancárias e carteiras de criptomoedas** Em **Configurações** > **Transferências**, você pode cadastrar na Ripple as contas bancárias e as carteiras de criptomoedas da sua própria organização. O recurso não é novo, mas não estava documentado. Quatro páginas novas o cobrem: - [Contas bancárias](/pt-br/products/payments-direct-2/user-interface/settings/bank-accounts) e [Adicionar uma conta bancária](/pt-br/products/payments-direct-2/user-interface/guides/add-a-bank-account) - [Carteiras de criptomoedas](/pt-br/products/payments-direct-2/user-interface/settings/crypto-wallets) e [Adicionar uma carteira de criptomoedas](/pt-br/products/payments-direct-2/user-interface/guides/add-a-crypto-wallet) Cada par cobre o que a página mostra e como concluir a tarefa, incluindo o que esperar enquanto a Ripple analisa uma carteira cadastrada por você. **Novas orientações sobre o seu primeiro depósito em produção** [Depositar recursos](/pt-br/products/payments-direct-2/user-interface/guides/deposit-funds) agora cobre dois pré-requisitos que não estavam documentados: - **Moeda fiduciária.** O crédito automático não fica habilitado quando a sua conta chega a produção pela primeira vez. Avise o seu contato na Ripple antes de enviar o primeiro depósito em produção para que a configuração única possa ser concluída. Apenas o primeiro depósito é afetado. - **Criptomoedas.** A carteira de origem precisa estar cadastrada na Ripple e aprovada pelo compliance antes de você abastecer a sua conta. **Correção nas orientações sobre destinos de saque** [Saques](/pt-br/products/payments-direct-2/introduction/concepts/withdrawals) antes orientava a contatar o suporte da Ripple para cadastrar um destino de saque. Os usuários com permissão para gerenciar os dados de onboarding da organização podem cadastrar destinos por conta própria em **Configurações** > **Transferências**. A página agora aponta para as páginas de autoatendimento e mantém o caminho do suporte para os usuários sem essa permissão. ### Agosto de 2026 details summary Clique para expandir **Novo tipo de instrumento financeiro: China CNY** `CN_BANK_PAYOUT` (`cnBankPayout`) agora está disponível para payouts em CNY para contas bancárias chinesas. O parceiro pagador escolhe entre CNAPS (conta bancária) e CUP (cartão UnionPay) na execução, portanto você não escolhe o payment rail. O instrumento recebe `bankName`, `bankCode`, `accountNumber` e `accountHolderName`. Envie o Ripple Bank Code em `bankCode`; use a [consulta de códigos bancários](/pt-br/products/payments-direct-2/api-docs/integration-resources/ripple-bank-codes) para encontrá-lo. `accountHolderName` é o nome da conta em caracteres hanzi chineses. As identidades usadas neste corredor têm requisitos adicionais: - Beneficiários pessoa física precisam do nome em caracteres hanzi chineses, nos novos campos `localized.hanzi.firstName` e `localized.hanzi.lastName` - O registro empresarial (`registration`) é obrigatório tanto para ordenantes quanto para beneficiários - Ordenantes pessoa física precisam de `identityDocuments` e `citizenship`; o `idType` do beneficiário é restrito a `NATIONAL_ID_NUMBER` Para a lista completa de campos, consulte [Instrumentos financeiros](/pt-br/products/payments-direct-2/introduction/concepts/financial-instruments) e o [Utilitário de schema de payload](/pt-br/products/payments-direct-2/api-docs/integration-resources/payload-schema-utility). **Novo campo de identidade: `localized`** As identidades agora têm um objeto `localized` para valores em escrita não latina, ao lado dos valores em escrita latina presentes no restante da identidade. O bloco `localized.hanzi` contém caracteres hanzi chineses (汉字) e é usado por pagamentos em CNY à China. Alguns campos deste bloco são exigidos no momento do pagamento, e não na criação da identidade. Eles são marcados como **Required at payment** no [Utilitário de schema de payload](/pt-br/products/payments-direct-2/api-docs/integration-resources/payload-schema-utility): a identidade é aceita sem eles, mas um pagamento que precise deles é rejeitado. **Novo campo de identidade: `originatorAccountNumber`** As identidades agora têm um campo dedicado `originatorAccountNumber` para o número da conta do próprio ordenante. A Ripple repassa esse valor ao parceiro pagador. O campo é obrigatório em identidades ORIGINATOR validadas em relação a `CN_BANK_PAYOUT` (pagamentos em CNY à China), `CN_CFXPS` (pagamentos em USD à China) ou `HK_BANK_PAYOUT` (pagamentos em HKD a Hong Kong), casos em que omiti-lo falha com 400 `USR_111`. É opcional em todos os demais corredores. Os valores precisam ser únicos entre todas as identidades ativas da sua organização, incluindo identidades de beneficiário, e duplicidades agora retornam o novo erro 409 [`USR_122`](/pt-br/products/payments-direct-2/api-docs/error-handling/api-errors). O `internalId` continua sendo a sua própria chave de referência de uma identidade. Ele não é o número da conta do ordenante. Para saber o que enviar, consulte [O número de conta do ordenante](/pt-br/products/payments-direct-2/introduction/concepts/payment-identities#o-n%C3%BAmero-de-conta-do-ordenante). As páginas dos corredores da China e de Hong Kong referenciadas nesta entrada foram removidas quando esses corredores foram retirados. **Novo erro de autenticação: `403 unauthorized_client`** O endpoint de token (`POST /v2/oauth/token`) agora pode retornar uma resposta `403` com `error: unauthorized_client` quando quem chama não está autorizado a solicitar um token. Isso se soma ao `403` já existente com `error: access_denied`, que indica que o serviço não está habilitado para o domínio solicitado. A mudança é aditiva e não afeta integrações autorizadas. Baseie o tratamento de erros de autenticação no código de status HTTP, e não na string `error`. Para mais informações, consulte [Erros de autenticação](/pt-br/products/payments-direct-2/api-docs/get-started/authentication#erros-de-autentica%C3%A7%C3%A3o). **Correção na documentação das respostas de erro das operações de pagamento** O formato documentado das respostas de erro da API de pagamentos estava incorreto. O campo `errors` é um **array** de objetos de erro, e `status` é um **inteiro** no nível superior da resposta, e não um campo de cada objeto de erro. **Nenhum comportamento da API mudou.** As operações de pagamento sempre retornaram esse formato. Estas correções alinham a especificação e a documentação ao que a API de fato retorna. Corrigido na referência da API e na [visão geral dos erros da API](/pt-br/products/payments-direct-2/api-docs/error-handling/payments-direct-api-errors): - `errors` agora está corretamente tipado como um array de objetos de erro - `status` agora está corretamente tipado como um inteiro no nível da resposta - Os exemplos de erro agora mostram valores corretos de `type`, `title` e `description`, correspondentes aos códigos de erro publicados Se você gera um cliente a partir da especificação do Payments Direct, gere-o novamente para incorporar os modelos de erro corrigidos. Os clientes gerados anteriormente não conseguiam desserializar as respostas de erro. **Correção no schema de resposta de transações do ledger e de saldos** Os tipos documentados de vários campos em `GET /v2/ledger-transactions` e `GET /v2/balances` estavam incorretos. Os campos monetários e de paginação são retornados como **strings**, não como números, e o parâmetro de consulta `page-size` não tem valor padrão aplicado pelo servidor. **Nenhum comportamento da API mudou.** Esses endpoints sempre retornaram esses valores como strings e sempre exigiram `page-size`. Estas correções alinham a especificação e a documentação ao que a API de fato retorna: - `amount`, `availableBalanceBefore` e `availableBalanceAfter` (transações do ledger) e `availableBalance` e `reservedBalance` (saldos) agora estão corretamente tipados como strings decimais (por exemplo, `"100.00"`) - `offset`, `pageSize`, `pageElements` e `total` (metadados de paginação) agora estão corretamente tipados como strings (por exemplo, `"25"`) - O parâmetro de consulta `page-size` não documenta mais um valor `default`; ele continua obrigatório, com mínimo de 1 e máximo de 50 - A descrição de `txnReference` não inclui mais uma afirmação incorreta sobre quando o campo é preenchido Se você gera um cliente a partir da especificação do Payments Direct, gere-o novamente para incorporar os modelos corrigidos. Para mais informações, consulte [Transações do ledger](/pt-br/products/payments-direct-2/introduction/concepts/ledger-transactions). **Respostas recém-documentadas para as operações de pagamento** Duas respostas que a API já retornava agora estão documentadas: - `415` em **Create payment**, **Search payments** e **Update payment labels**, retornado quando o cabeçalho `Content-Type` está ausente ou não é aceito - `403` em **Create payment**, retornado quando o pagamento existe mas pertence a outro tenant Ambas documentam, de forma aditiva, comportamentos já existentes. Para a lista completa, consulte [Erros da API](/pt-br/products/payments-direct-2/api-docs/error-handling/api-errors). ### Julho de 2026 details summary Clique para expandir **Novos tipos de instrumento financeiro: Japão e Austrália** Dois novos tipos de instrumento financeiro estão disponíveis: - `JP_ZENGIN` (`jpZengin`) — pagamentos em JPY para contas bancárias japonesas via Zengin, com o Zengin Prompt Service para transferências de baixo valor em tempo real - `AU_NPP` (`auNpp`) — pagamentos em AUD para contas bancárias australianas via NPP, com Direct Entry (BECS) como alternativa para alto valor e lotes Para detalhes por campo, consulte [Instrumentos financeiros](/pt-br/products/payments-direct-2/introduction/concepts/financial-instruments). **Novos tipos de instrumento financeiro: Oriente Médio, Ásia-Pacífico, Europa e América Latina** Dez novos tipos de instrumento financeiro estão disponíveis: - `AE_IPI` (`aeIpi`) — pagamentos em AED para contas bancárias dos Emirados Árabes Unidos via IPI, com FTS como alternativa para transferências de maior valor - `IN_NEFT` (`inNeft`) — pagamentos em INR para contas bancárias indianas via NEFT - `ID_BIFAST` (`idBifast`) — pagamentos em IDR para contas bancárias indonésias via BI-FAST - `TR_FAST` (`trFast`) — pagamentos em TRY para contas bancárias turcas via FAST, com EFT como alternativa para transferências de maior valor - `PH_NRPS` (`phNrps`) — pagamentos em PHP para contas bancárias filipinas via InstaPay, com PESONet como alternativa para transferências de maior valor - `CL_TEF` (`clTef`) — pagamentos em CLP para contas bancárias chilenas via TEF - `TH_PROMPTPAY` (`thPromptpay`) — pagamentos em THB para contas bancárias tailandesas via PromptPay - `KR_KFTC` (`krKftc`) — pagamentos em KRW para contas bancárias sul-coreanas via KFTC - `PE_LBTR` (`peLbtr`) — pagamentos em PEN para contas bancárias peruanas via LBTR - `AR_INTERBANKING` (`arInterbanking`) — pagamentos em ARS para contas bancárias argentinas via Interbanking Para detalhes por campo de todos os novos tipos de instrumento, consulte [Instrumentos financeiros](/pt-br/products/payments-direct-2/introduction/concepts/financial-instruments). **Restrições de tipo de documento de identidade por corredor** Alguns corredores agora aceitam apenas um subconjunto do enum de tipo de documento de identidade para cada papel de pagamento. As requisições que usam um valor não aceito em `identityDocuments.type` / `idType` (pessoa física) ou `registration.type` (empresa) são rejeitadas com um **erro 400**. A imposição se baseia nos corredores em `validatePayoutRails` (na criação da identidade) ou no tipo de instrumento financeiro (na criação do instrumento). Por exemplo, beneficiários empresa nos corredores `ETH_WALLET`, `SOL_WALLET` e `TRON_WALLET` precisam usar `INCORPORATION_CERTIFICATE`. Para ver os valores aceitos por corredor e papel, consulte [Tipos de documento aceitos por corredor](/pt-br/products/payments-direct-2/introduction/concepts/payment-identities#tipos-de-documento-aceitos-por-corredor). ### Junho de 2026 details summary Clique para expandir **Novos tipos de instrumento financeiro: China** Um novo tipo de instrumento financeiro atende a um cenário adicional de pagamento na China: - `CN_CFXPS` (`cnCfxps`) — payouts em USD à China via China Foreign Exchange Payment System (CFXPS) **Novos tipos de instrumento financeiro: carteiras de criptomoedas** Três novos tipos de instrumento financeiro atendem a pagamentos em stablecoin para endereços de carteiras de criptomoedas: - `ETH_WALLET` (`ethWallet`) — pagamentos em USDT, USDC e RLUSD na rede Ethereum - `TRON_WALLET` (`tronWallet`) — pagamentos em USDT na rede Tron - `SOL_WALLET` (`solWallet`) — pagamentos em USDC na rede Solana Todos os instrumentos de carteira de criptomoedas retornam `ZZ` no campo de metadados `country`. **Novo tipo de instrumento financeiro: pagamento bancário em Hong Kong** `HK_BANK_PAYOUT` (`hkBankPayout`) permite pagamentos em HKD para contas bancárias de Hong Kong via CHATS. Os campos obrigatórios incluem `bankName`, `accountNumber`, `accountHolderName` e `swiftCode`. É exigida pré-autorização de todos os remetentes. **Novos tipos de instrumento financeiro: pagamentos bancários na África** Cinco novos tipos de instrumento financeiro para pagamentos bancários africanos estão disponíveis, permitindo a expansão dos corredores da era NGN a novos mercados: - `GH_BANK_PAYOUT` (`ghBankPayout`) — Gana (GHS), via GIS - `RW_BANK_PAYOUT` (`rwBankPayout`) — Ruanda (RWF), via RSwitch - `ZA_BANK_PAYOUT` (`zaBankPayout`) — África do Sul (ZAR), via PayShap. Caso de uso compatível: apenas C2B2C. - `UG_BANK_PAYOUT` (`ugBankPayout`) — Uganda (UGX) - `ZM_BANK_PAYOUT` (`zmBankPayout`) — Zâmbia (ZMW), via ZECHL Para detalhes por campo de todos os novos tipos de instrumento, consulte [Instrumentos financeiros](/pt-br/products/payments-direct-2/introduction/concepts/financial-instruments). **Consulta de códigos bancários** O utilitário de consulta de códigos bancários agora cobre todos os corredores compatíveis em uma única interface. Selecione o país de destino para ver os códigos bancários disponíveis; nos países com várias moedas, selecione a moeda para refinar os resultados. - **Nigéria (NGN):** retorna Ripple Bank Codes (RBCs) no formato `RPL:NG:[ALIAS]:BNK`. - **China (CNY):** retorna códigos CNAPS (China National Advanced Payment System). - **China (USD):** retorna códigos SWIFT/BIC. Para mais informações, consulte [Códigos bancários](/pt-br/products/payments-direct-2/api-docs/integration-resources/ripple-bank-codes). ### Abril de 2026 details summary Clique para expandir **Novo modelo de financiamento: just-in-time (JIT) funding** Um novo valor de `payinCategory`, `JIT_FUNDING`, está disponível na criação de cotações. Os pagamentos financiados via JIT entram no novo estado `AWAITING_FUNDING` após a criação e prosseguem assim que os recursos são recebidos na sua conta de ledger da Ripple, antes do prazo de `jitFundingExpiresAt`. Para mais informações, consulte [Modelo de financiamento](/pt-br/products/payments-direct-2/introduction/concepts/quotes#modelo-de-financiamento-payincategory) e [Estados do pagamento](/pt-br/products/payments-direct-2/introduction/concepts/payment-lifecycle). **Novos valores de payinCategory: `PRE_FUNDING` e `CREDIT_FUNDING`** Dois novos valores de `payinCategory` são introduzidos como substitutos preferenciais dos valores obsoletos: - `PRE_FUNDING` substitui `FUNDED` - `CREDIT_FUNDING` substitui `T_PLUS_ONE` Os valores obsoletos `FUNDED` e `T_PLUS_ONE` continuam a ser aceitos nos endpoints de cotação v2 e não serão removidos no momento. As novas integrações devem usar os novos valores. **Novo estado de pagamento: `AWAITING_FUNDING`** Um novo estado de pagamento não terminal, `AWAITING_FUNDING`, é introduzido para os pagamentos financiados via JIT. Para mais informações, consulte [Estados do pagamento](/pt-br/products/payments-direct-2/introduction/concepts/payment-lifecycle). **Novos campos na resposta de pagamento: `payoutExecutionDetails` e `jitFundingExpiresAt`** A resposta de `GET /v3/payments/{paymentId}` agora inclui dois novos campos: - `payoutExecutionDetails` (opcional): metadados sobre como um pagamento foi executado, incluindo `paymentRailUsed`, `payoutStartTime`, `payoutEndTime` e `trackingReferences` (identificadores específicos da rede, como IMAD/OMAD no Fedwire). A cobertura varia por corredor e parceiro. Para mais informações, consulte [Detalhes de execução do payout](/pt-br/products/payments-direct-2/introduction/concepts/payment-execution-details). - `jitFundingExpiresAt`: presente nos pagamentos financiados via JIT; indica o prazo até o qual os recursos precisam ser transferidos para a sua conta de ledger da Ripple para que o pagamento prossiga. **Novo endpoint da API: `GET /v3/identities/by-internal-id/{internal-id}`** Agora você pode recuperar uma identidade ativa usando o seu próprio `internalId`, sem precisar do `identityId` gerado pela Ripple. O endpoint retorna apenas identidades no estado `ACTIVE` e sempre retorna a versão mais recente. Para mais informações, consulte [Criar e gerenciar identidades](/pt-br/products/payments-direct-2/api-docs/developer-guides/create-and-manage-identities). **Tipo de instrumento financeiro renomeado: `AFRICA_BANK_PAYOUT` agora é `NG_BANK_PAYOUT`** O tipo de instrumento financeiro de pagamento bancário na África foi renomeado de `AFRICA_BANK_PAYOUT` para `NG_BANK_PAYOUT`. Atualize qualquer código de integração, array `validatePayoutRails` de identidade ou ferramenta interna que referencie o valor antigo. Para mais informações, consulte [Instrumentos financeiros](/pt-br/products/payments-direct-2/introduction/concepts/financial-instruments). **Redução dos requisitos de dados para US ACH** Com base no retorno dos clientes, os seguintes campos de identidade deixaram de ser obrigatórios na criação de tokens de identidade para pagamentos US ACH: - `registration` — não é mais obrigatório nas identidades BUSINESS ORIGINATOR e BUSINESS BENEFICIARY - `identityDocuments` — não é mais obrigatório nas identidades INDIVIDUAL BENEFICIARY Para uma lista atualizada dos campos obrigatórios por corredor, use o [Utilitário de Schema de Payload](/pt-br/products/payments-direct-2/api-docs/integration-resources/payload-schema-utility). **Correção no schema de resposta de `GET /v2/ledger-transactions`** O schema de resposta de `GET /v2/ledger-transactions` estava definido incorretamente como um array. Ele foi corrigido para um objeto contendo os metadados de paginação (`offset`, `pageSize`, `pageElements`, `total`) e um array `statementTransactions`. Os clientes que usam geradores OpenAPI sobre uma versão anterior desta especificação podem precisar gerar novamente o código do cliente. O schema de resposta `text/csv` também foi corrigido e agora inclui a documentação das colunas e uma linha de exemplo. ### Março de 2026 details summary Clique para expandir **Versionamento da documentação: v2026.03 e v2025.11** A documentação do Payments Direct agora é versionada. Use o seletor de versão para alternar entre as versões: - **v2026.03 (esta versão)** - documenta a API do Payments Direct com o **Identity Management v3**, incluindo os endpoints v3 de identidade e de instrumento financeiro. - **v2025.11** - documenta a API do Payments Direct com o **Identity Management v2**. ### Janeiro de 2026 details summary Clique para expandir **Novo endpoint da API: `GET /v2/ledger-transactions`** Fornece uma lista paginada de transações do ledger e saldos correntes em um intervalo de tempo UTC especificado, apoiando a conciliação do cliente e os relatórios operacionais. Para mais informações, consulte [Transações do ledger](/pt-br/products/payments-direct-2/introduction/concepts/ledger-transactions). **Novo estado de pagamento: `RETURNED`** Os pagamentos que haviam sido marcados como `COMPLETED` mas foram revertidos depois pelo parceiro pagador ou pela rede agora são marcados como `RETURNED`. Para mais informações, consulte [Ciclo de vida do pagamento](/pt-br/products/payments-direct-2/introduction/concepts/payment-lifecycle) e [Devoluções de pagamento](/pt-br/products/payments-direct-2/introduction/concepts/payment-returns). **Melhoria de recurso: transparência tributária** Introduzimos uma estrutura detalhada de detalhamento de tributos nas respostas de **Quote** e de **Payment** para apoiar o reporte transparente das obrigações tributárias e das tarifas de serviço. ### Novembro de 2025 details summary Clique para expandir **Melhorias e expansões do payout network** - Lançamento do recurso Transaction Memo para pagamentos em EUR/GBP - Pagamentos habilitados: PHP, CN-USD e INR ### Outubro de 2025 details summary Clique para expandir **Melhorias e expansões do payout network** - Lançamento do recurso Transaction Memo para pagamentos em USD - Pagamentos habilitados: AED, AUD, CLP, COP, JPY, IDR, KRW, PEN, THB e VND ### Setembro de 2025 details summary Clique para expandir **Melhorias** - Lançamento dos pagamentos FedWire com o Lead Bank - Lançamento de melhorias no benchmark de câmbio para reduzir as diferenças de preço com as stablecoins ### Agosto de 2025 details summary Clique para expandir **Melhorias** - Lançamento do recurso Maker/Checker no Payments Direct, viabilizando fluxos de aprovação de pagamentos - Lançamento da especificação OpenAPI do Payments Direct, disponível para download [aqui](https://github.com/ripple/payments-direct/blob/main/openapi_spec/rpd2_spec.yml). ### Julho de 2025 details summary Clique para expandir **Melhorias** - Lançamento dos recursos de off-ramp para entregar RLUSD ### Junho de 2025 details summary Clique para expandir **Novos mercados de pagamento habilitados** - Pagamentos RTP habilitados nos Estados Unidos - Pagamentos em EUR/GBP habilitados ### Maio de 2025 details summary Clique para expandir **Novos mercados de pagamento habilitados** - Pagamentos habilitados para BRL, CNY, GHS, NGN, RWF, ZAR, UGX e ZMW ### Abril de 2025 details summary Clique para expandir **Melhorias e expansões de rede** - Pagamentos ACH habilitados com o iPayout - Payments Direct lançou on-ramps para que os clientes enviem stablecoins, começando por USDC e USDT - Fluxo de pagamento redesenhado no Payments Direct para simplificar e aprimorar a experiência do usuário ### Março de 2025 details summary Clique para expandir **Beta dos off-ramps lançado** Beta dos off-ramps lançado para os clientes do Payments Direct, permitindo que eles paguem em stablecoins nos principais mercados de pagamento ### Fevereiro de 2025 details summary Clique para expandir **Lançamento oficial do Payments Direct** Payments Direct permite que você se conecte à Ripple como provedor de pagamentos. A Ripple cuida da entrega dos pagamentos aos beneficiários, da gestão dos parceiros pagadores, do fornecimento de recursos a esses parceiros e do pagamento dos encargos em troca da entrega dos pagamentos aos beneficiários. Com o Payments Direct, você pode enviar pagamentos e gerenciar beneficiários pelo Payments Direct UI.