Construir uma linha temporal
O utilizador pede verificação da conta A através de Q1. Enquanto espera, muda o rascunho para B e origina Q2. A resposta Q2 é NMTC; mais tarde chega MTCH de Q1. Uma interface que escolhe a última resposta recebida confirma falsamente B. Desenhar a linha temporal antes de escrever código torna a causa observável. No modelo, a assinatura inclui revisão, ambiente, modo, conta e parte. Só a resposta associada ao snapshot atual é aplicável. Esta é uma política conservadora original da DR, não uma regra universal do EPC para revisões de interface.
Preservar identidade e contexto
O registo local aceita repetir a mesma chave com o mesmo snapshot e recusa reutilizá-la para dados diferentes. A propriedade é limitada ao dicionário em memória. Não prova execução financeira única nem idempotência de um serviço remoto. DR-Q1 é um rótulo didático; não satisfaz a exigência de UUID dos cabeçalhos reais, que o programa não valida. Num projeto, pedir a política de identidade, âmbito entre ambientes, conservação e tratamento de colisões. Guardar apenas o código MTCH perde a ligação aos dados verificados. Cancelar um pedido antigo pode melhorar a experiência, mas não substitui a verificação da associação quando uma resposta chega.
Definir a duração antes de a calcular
O intervalo inter-PSP VOP tem um máximo de cinco segundos entre envio do pedido e receção da resposta pelo solicitante. Não usar o limite de outro fluxo de pagamentos. Na fixture, 1000 até 6000 milissegundos cumpre a fronteira; 6001 ultrapassa-a. Estes números são sintéticos, não medições de desempenho. Para instrumentação real, definir marcos correlacionados e um relógio adequado à medição local do intervalo. Subtrair timestamps de máquinas diferentes sem conhecer a sua relação pode produzir resultados negativos. Um relógio monotónico ajuda a medir durações locais, enquanto tempo de CPU não inclui toda a espera de rede.
Escolher denominadores e preservar finalidade
O conjunto fictício contém cem pedidos: oitenta MTCH, dez NMTC, cinco NOAP e cinco erros API. Dizer que cem respostas representam cem verificações positivas confunde receção com resultado. Apresentar oitenta por cento MTCH sobre todos os pedidos e manter as outras categorias visíveis. Uma taxa calculada apenas sobre comparações realizadas precisa de outro denominador explícito. O PM deve conseguir explicar ambos ao sponsor. As respostas também não constituem autorização genérica para criar um diretório comercial de titulares. Definir acesso, finalidade e retenção com os responsáveis; o laboratório usa apenas nomes inventados e não estabelece uma política de conservação para um banco.
Preparar a decisão em inglês
Na oficina de 45 minutos abaixo, o grupo recebe uma corrida entre respostas, uma medição negativa e um pedido de aceitação final. Preparar um resumo em inglês com observado, impacto, ação, responsável e próxima atualização. Por exemplo, dizer que a resposta antiga não pertence ao rascunho atual é mais preciso do que anunciar falha de todas as verificações. Não anexar credenciais ou dados pessoais. Identificar quais conclusões dependem do modelo e quais exigem o fornecedor ou um ambiente autorizado. A passagem à operação deve permitir que outra pessoa reconstrua o caso a partir dos dados sanitizados e dos resultados esperados.
Distinguir exercício e aceitação
Executar o laboratório, trocar uma dimensão da assinatura e prever quais respostas deixam de ser aplicáveis. Depois repetir o cenário em que Q2 chega antes de Q1. As 40 verificações cobrem parsing, contrato limitado, associação e fronteiras aritméticas. Não existe browser automatizado dentro do programa, chamada HTTP ou medição de rede. A interface descrita é um caso de decisão. Registar presença numa oficina apenas se esta ocorrer; prática individual é autoavaliação. Para aceitação real, listar as dependências não ensaiadas e acordar evidência com os responsáveis. Concluir este percurso não atribui certificação EPC nem demonstra prontidão operacional de uma integração bancária.
DR original workshop / Oficina original DR: 45 minutes
Synthetic fixtures only. No requests, real accounts, credentials or payments.
Apenas fixtures sintéticas. Sem pedidos, contas reais, credenciais ou pagamentos.
0-10 min: Predict / Prever
Q1: revision=1, account=ACCOUNT-A. Q2: revision=2, account=ACCOUNT-B.
Q2 returns NMTC. Q1 later returns MTCH. Current revision remains 2.
Q2 devolve NMTC. Q1 devolve MTCH depois. A revisão atual continua a ser 2.
Expected: Q1 is stale for the current draft; retain Q2's applicable outcome.
Esperado: Q1 é antigo para o rascunho atual; manter o resultado aplicável de Q2.
10-20 min: Diagnose / Diagnosticar
100 requests = 80 MTCH + 10 NMTC + 5 NOAP + 5 API errors.
Report 80% MTCH over all requests; preserve every other category.
Reportar 80% MTCH sobre todos os pedidos; conservar as restantes categorias.
Synthetic timing: sent=1000ms, received=6001ms; elapsed=5001ms.
Tempo sintético: envio=1000ms, receção=6001ms; duração=5001ms.
Negative cross-clock duration cannot establish compliance.
Uma duração negativa entre relógios não demonstra cumprimento.
20-35 min: English decision note / Resumo de decisão em inglês
Observed: a late response overwrites the current draft's result.
Impact: the interface may display verification for different data.
Action: bind observations to immutable request snapshots and draft revisions.
Owner: nominate the adapter and frontend owners; agree a specific update time.
Evidence: sanitized timeline, contract versions, expected and actual outcomes.
Acceptance: local fixture evidence only; external dependencies remain open.
Não incluir tokens ou dados pessoais. Não afirmar autorização de pagamento.
Do not include tokens or personal data. Do not claim payment authorization.
35-45 min: Handover / Passagem à operação
Another participant reruns the model and explains the remaining evidence.
Outro participante repete o modelo e explica a evidência ainda em falta.
Record self-review for solo practice, not independent operational acceptance.
Na prática individual, registar autoavaliação, não aceitação operacional independente.
Deliver code hash, fixtures, predictions, actual results, owners and open questions.
Entregar hash, fixtures, previsões, resultados, responsáveis e questões abertas.
Caso: um MTCH tardio de Q1 substitui NMTC de Q2 após editar a conta. Conservar Q1 no seu histórico e manter a observação aplicável à revisão atual.
Armadilhas comuns
Usar ordem de chegada como atualidade; reutilizar identidades; interpretar duração negativa como rapidez; declarar qualificação externa com testes locais.
Tópicos relacionados: Prazos, confirmações e resultados tardios · Mandatos, Core e B2B · Alterações e prontidão operacional
A decisão depende de uma observação ligada ao pedido correto e de medições definidas; o relatório deve conservar as incertezas e a evidência ainda em falta.
Referência: EPC Verification Of Payee rulebook 1.1 · DR Payments and SEPA professional assessment2026.10