Requisitos de Dados da China (USD)

Analise estas limitações antes de enviar neste corredor e oriente seus clientes conforme necessário. Todas as quatro são conhecidas e acompanhadas, e ainda não há datas de correção confirmadas.

• Alguns bancos de beneficiários são compatíveis apenas com os casos de uso B2B e B2B2B. Escolher um deles para qualquer outro caso de uso não é rejeitado na criação do pagamento. O pagamento segue o roteamento mesmo assim e pode falhar cerca de 4 a 5 dias úteis depois, com um erro genérico. A consulta Códigos bancários ainda não mostra com quais casos de uso cada banco é compatível; o suporte por banco está sendo confirmado e será adicionado lá.
• Os valores SWIFT/BIC do beneficiário não são validados na criação do pagamento. Um BIC inválido, ou um BIC de agência em vez de um BIC de matriz, é aceito e falha da mesma forma.
• Os comprimentos máximos exibidos no Payments Direct UI ao criar um beneficiário pessoa física podem não corresponder aos limites documentados nesta página. Os limites desta página são os que o parceiro pagador aplica. A API não os impõe, então um valor que os ultrapasse é aceito na criação e falha depois, no payout.
• Envie um pagamento de teste de baixo valor para cada caso de uso antes de aumentar o volume. O penny testing neste corredor é limitado pela regulamentação local, então a cobertura da própria Ripple ainda está em andamento.

Nos pagamentos em USD à China, COMPLETED significa que os recursos chegaram ao banco do beneficiário. Isso nem sempre significa que a conta do beneficiário foi creditada.

Na maioria dos casos, o banco do beneficiário primeiro analisa o pagamento para fins de compliance, porque os controles cambiais chineses exigem análise de todo pagamento em USD recebido, independentemente do valor. O banco entra em contato diretamente com o beneficiário para obter documentação comprobatória, como nota fiscal, comprovante de embarque ou alfandegário, contrato de trabalho ou comprovante de vínculo. Em uma minoria dos casos, ele credita a conta imediatamente. Não é possível saber de antemão o que vai acontecer.

Esse processo está fora do controle da Ripple e não há SLA aplicável. O crédito costuma levar vários dias úteis e pode levar semanas se o banco escalar para due diligence reforçada. O prazo depende de quando o beneficiário fornece documentação satisfatória. Alinhe as expectativas com seus beneficiários de acordo com isso e não trate COMPLETED como comprovante de recebimento.

Depois que um pagamento é iniciado, não é possível cancelá-lo, alterá-lo nem solicitar estorno ou devolução. Apenas o banco do beneficiário pode iniciar uma devolução, o que ocorre quando o pagamento não passa na análise de compliance.

Um pagamento devolvido pode valer menos do que o valor enviado, porque o banco que devolve pode descontar uma tarifa de processamento. As tarifas variam por banco e agência, então considere essa diferença ao conciliar devoluções.

Como um pagamento não pode ser corrigido após o envio, confira os dados do beneficiário antes de enviar. Valores enviados a um beneficiário não pretendido geralmente não são recuperáveis, e dados incorretos ou incompletos podem atrasar um pagamento ou fazer com que ele se perca.

originatorAccountNumber e internalId são campos diferentes, e a diferença importa aqui. Se você deixar originatorAccountNumber vazio, a Ripple envia internalId ao parceiro pagador no lugar dele, como número da conta do ordenante.

Isso raramente é o que você quer. internalId é a sua própria chave de referência e, no Payments Direct UI, é gerado automaticamente como um UUID que você nunca vê. Um UUID de 36 caracteres também excede o limite de 34 caracteres acima.

Envie o número da conta em originatorAccountNumber. Não o envie em internalId, que tem sua própria regra de unicidade.

Nenhum desses dois limites é validado pela API. Ambos são aplicados pelo CFXPS depois que o pagamento é enviado, e eles se comportam de forma diferente:

• Um caractere não compatível rejeita o pagamento. O CFXPS o devolve, então você fica sabendo.
• Um nome ou endereço longo demais é truncado, não rejeitado. O CFXPS encurta o nome e o endereço combinados para caber e encaminha o pagamento. Nada avisa que isso aconteceu, e o banco do beneficiário pode devolver ou encaminhar incorretamente um pagamento que chega com o nome ou o endereço encurtado.

O truncamento é o mais prejudicial dos dois, porque o dinheiro se movimenta com dados incorretos. Trate os limites de comprimento abaixo como requisitos rígidos, ainda que nada os imponha na entrada.

O campo address.streetAddress é um array, portanto a API aceita mais de uma entrada. Somente a primeira entrada é entregue neste corredor. Qualquer conteúdo em uma segunda entrada ou posterior é descartado em trânsito.

Isso é pior do que perder uma linha de endereço. O estado ou província e o código postal são anexados à última entrada, de modo que, com duas ou mais entradas, eles são anexados a uma linha que nunca é entregue, e o banco do beneficiário recebe um endereço sem estado e sem código postal. É por isso que a interface da Ripple envia uma única linha, e quem envia pela API deve fazer o mesmo.

Coloque todo o endereço na primeira entrada e não envie outras.