Programador 7 min de leitura

Gerir timeouts e retries na Verification of Payee

Toda integração de Verification of Payee acaba por encontrar um banco respondente lento ou inacessível. A diferença entre uma integração robusta e uma frágil é como trata o timeout.

Por Verification of Payee EU · com tecnologia RoxPay

Gerir timeouts e retries na Verification of Payee

Em resumo

  • Defina um timeout síncrono sensato e trate o excesso como não disponível, não como uma falha grave.
  • Repita com backoff, mas apenas com pedidos idempotentes indexados por um identificador estável.
  • Defina uma política de fallback clara para o pagador quando não se consegue obter um resultado a tempo.

A Verification of Payee depende de uma resposta remota do banco do beneficiário. Quando esse banco está lento, sobrecarregado ou temporariamente inacessível, a sua integração tem de decidir o que fazer — e essa decisão afeta tanto a experiência do pagador como a sua posição de conformidade. Os piores resultados são um checkout congelado ou uma verificação cobrada ou contada duas vezes em silêncio.

O resultado não disponível é uma funcionalidade

O esquema define um resultado não disponível precisamente para que não tenha de inventar a semântica de erros. Quando o lado respondente não consegue responder a tempo, trate-o como um resultado de primeira classe em vez de uma exceção.

  • Defina um timeout síncrono alinhado com o seu orçamento de checkout (muitas vezes alguns segundos).
  • Em caso de excesso, apresente ao pagador um estado neutro não disponível em vez de um erro alarmante.
  • Decida, por política, se o pagador pode prosseguir, deve aguardar ou deve ser encaminhado para revisão.

Repetir em segurança

Os retries ajudam com falhas transitórias mas causam danos se não forem idempotentes. Um retry nunca deve criar uma segunda verificação lógica ou uma segunda cobrança.

  1. 1 Associe um identificador de pedido estável a cada tentativa de verificação.
  2. 2 Repita os erros de rede transitórios com backoff exponencial e um teto pequeno.
  3. 3 Nunca repita um resultado definitivo (correspondência, correspondência parcial, sem correspondência) — repita apenas as verdadeiras falhas de transporte.
  4. 4 Reconcilie qualquer resposta tardia com o identificador de pedido para que seja registada uma só vez.

Orce a espera, depois decida

Escolha um orçamento síncrono que consiga defender perante as suas equipas de UX e conformidade. Para além desse orçamento, recue deliberadamente — mostre pendente ou não disponível — em vez de deixar o pedido pendurado e o pagador abandonar.

A RoxPay devolve os resultados padronizados incluindo não disponível, suporta retries idempotentes por ID de pedido, e recua para um webhook para as respostas tardias — para que a sua política de timeout se mantenha simples.

FAQ

Perguntas frequentes

Alinhe-o com a sua experiência de checkout — muitas vezes alguns segundos para uso síncrono. Para além disso, recue para um estado pendente ou não disponível em vez de bloquear o pagador indefinidamente.

Apenas para falhas de transporte, e apenas com pedidos idempotentes indexados por um identificador estável. Nunca repita um resultado de correspondência definitivo; é um resultado, não um erro.

Trate-o como um resultado definido e aplique a sua política: permitir ao pagador prosseguir com cautela, aguardar uma resposta assíncrona ou encaminhar o pagamento para revisão manual consoante o risco.

Torne a VoP fiável em produção

Fale com a RoxPay sobre timeouts, retries idempotentes e fallbacks de webhook no esquema SEPA VoP.