Histórico de alterações

O validatePayoutRails agora é validado ao criar uma identidade

O POST /v3/identities agora valida todos os valores em validatePayoutRails, igualando o comportamento do PUT /v3/identities/{identity-id}. Um valor que não seja um payment rail atualmente oferecido falha com 400 Bad Request (USR_111).

Antes, a criação aceitava valores não reconhecidos sem reclamar e validava os campos da identidade apenas para os rails que reconhecia. Se você enviar um nome de rail com erro de digitação ou que não seja mais oferecido, uma requisição que antes era bem-sucedida agora falha. Verifique os valores que envia em validatePayoutRails em relação à lista de financialInstrumentType antes de depender deste endpoint.

Os payouts para a Turquia (TRY) estão pausados

Os payouts para a Turquia em TRY estão pausados enquanto a revisão regulatória está pendente. O corredor continua listado no payout network com um indicador de pausa, e seus limites de transação e a entrada de payment rail continuam publicados, mas os pagamentos não podem ser enviados enquanto a pausa estiver em vigor.

Correção da orientação sobre idempotência e novas tentativas de pagamento

A orientação sobre repetir uma requisição de criação de pagamento estava incorreta. Ela descrevia o internalId como chave de idempotência e orientava verificar a existência de um pagamento com GET /v3/payments, uma operação que não existe. O /v3/payments tem apenas POST (Create payment), e a busca de pagamentos é POST /v3/payments/filter.

Nenhum comportamento da API mudou. A criação de pagamentos sempre foi deduplicada por quoteId: uma cotação produz no máximo um pagamento, e reenviar uma requisição para uma cotação que já tem um pagamento retorna esse pagamento com 201, mesmo após a cotação expirar. Os valores de internalId de pagamento nunca foram verificados quanto à unicidade, portanto duas requisições com o mesmo internalId e valores diferentes de quoteId criam dois pagamentos.

Se você construiu o tratamento de novas tentativas com base na orientação anterior, revise-o. Repetir com uma nova cotação após um timeout pode criar um pagamento duplicado, e uma verificação de nova tentativa contra GET /v3/payments não pode ser bem-sucedida. Consulte Idempotência e novas tentativas seguras.

A página Polling foi corrigida na mesma revisão: a busca em lote era descrita como POST /v3/payments, que é a operação de criação de pagamento (Create payment). Os corpos de requisição mostrados já estavam corretos para a busca; apenas o caminho estava errado.

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).

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 identityDocuments.

Consulte Requisitos por jurisdição.

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) 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.

Analise as limitações conhecidas na página de requisitos de dados de transação da China (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 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 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 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.

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 e Adicionar uma conta bancária
• Carteiras de criptomoedas e Adicionar uma carteira de criptomoedas

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 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 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.

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 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 e o Utilitário de schema de payload.

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: 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.

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. 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.

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:

• 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.

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.

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.

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.

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.

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.

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.

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 e Estados do pagamento.

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.

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.
• 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.

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.

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.

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.

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.

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.

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 e Devoluções de pagamento.

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.

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

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

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

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.

Melhorias

• Lançamento dos recursos de off-ramp para entregar RLUSD

Novos mercados de pagamento habilitados

• Pagamentos RTP habilitados nos Estados Unidos
• Pagamentos em EUR/GBP habilitados

Novos mercados de pagamento habilitados

• Pagamentos habilitados para BRL, CNY, GHS, NGN, RWF, ZAR, UGX e ZMW

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

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

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.