Status, periodiske statusforespørsler og avstemming

Spørring fra backend

: "${WR_API_KEY:?Defina WR_API_KEY en el entorno seguro de su backend}"

curl --request POST 'https://api.wealthreader.com/payments/?action=status' \
  --header 'Content-Type: application/json' \
  --header "X-API-Key: ${WR_API_KEY}" \
  --data '{
    "payment_intent_id": "11111111-1111-4111-8111-111111111111",
    "refresh": true
  }'

refresh er valgfritt og true som standard. Wealth Reader begrenser eksterne forespørsler etter intensjon; bruk backoff også på din backend og ikke skap en ny intensjon så lenge resultatet er tvetydig.

Tre forskjellige dimensjoner

Den eneste positive bekreftelsen er payment_status: settled, basert på en eksplisitt bankstatus som bekrefter oppgjør. Et teknisk resultat DONE, interaction_status: completed eller payment_status: pending utgjør aldri oppgjør.

Tvetydig resultat

Et ukjent nettverksavbrudd, timeout eller respons etter at starten er utstedt, endrer intensjonen til reconciliation_required og eksponerer payment_status: unknown. Starten gjentas ikke automatisk.

Den nåværende leverandøren tilbyr ikke en spørring som rekonstruerer en initiering hvis svar gikk tapt: tilstandsspørringen krever den ugjennomsiktige konteksten returnert av samme initiering. Derfor krever det tilfellet manuell avstemming; det kan ikke hentes ved periodisk spørring av den automatiske tilstanden eller ved å søke etter callback-ID-en.

I så fall:

1. behold idempotensnøkkelen og identifikatoren;
2. skaper ikke en annen intensjon eller autoriserer igjen;
3. Se den autentiserte statusen til Wealth Reader og behold din sikre avstemmingsreferanse;
4. Kontakt teknisk support; ikke fortsett å sjekke status når automatic_recovery er false.

For en intensjon som krever manuell avstemming, kan server-til-server-spørringen inkludere:

{
  "payment_status": "unknown",
  "reconciliation_required": true,
  "reconciliation": {
    "automatic_recovery": false,
    "reference": "wrp_recon_0123456789abcdef0123",
    "request_id": "11111111-1111-4111-8111-111111111111",
    "correlation_id": "22222222-2222-4222-8222-222222222222",
    "reason": "initiation_rejected"
  }
}

Disse identifikatorene er referanser uten sensitive opplysninger, beregnet på support. De leveres ikke til widgeten og lar ikke kunden spørre eller rekonstruere leverandørens interne tilstand.

reason er en Wealth Readerkode, aldri leverandørens tekst. initiation_rejected indikerer at leverandøren svarte med en definitiv avvisning av initieringen; initiation_response_unavailable, at det ikke var noe gjenkjennelig svar. I begge tilfeller er initieringen allerede overført, så den gjentas ikke: behold referansen og kontakt teknisk support.

Tilbakekalling og repris

Returen fra SCA kommer til en dedikert callback for betalinger. Wealth Reader validerer korrelasjonen, videresender bankens parametere til leverandøren slik de er (uforutsette navn registreres, de avviser aldri en allerede autorisert retur), konsumerer returen kun én gang, og bevarer den krypterte sensitive tilstanden. En gjentakelse svarer kun HTTP 409; den avhenger ikke av en intern kode i brødteksten.

Autentisering kan kreve flere omdirigeringer. Hver validert REDIRECT fortsetter i samme SCA vindu og åpner et nytt callbacksjekkpunkt; det oppretter ikke en ny initiering. Et resultat DECOUPLED holder intensjonen i processing for at widgeten skal spørre om status. En eksplisitt RETRY gjentar kun den fullføringen som allerede er forberedt, med begrenset ventetid og antall forsøk. ERROR, PASSWORD, MORE_INFO, SELECT_OPTION, et ukjent resultat eller uttømming av disse grensene ender i avstemming, aldri i en ny initiering.

Forhandleren trenger ikke å publisere eller behandle dette callback. Denne utgivelsen sender ikke webhooks til forhandleren: den offentlige kontrakten for betalingsbekreftelse er den periodiske forespørselen om server-til-server-tilstanden.

Lukker widgeten

flow_closed kommuniserer at den synlige interaksjonen er avsluttet. Frontend kan lukke modalen, men den må ikke vises "betalt" for den hendelsen. Backend beholder ansvaret for å bekrefte eller avstemme betalingen.

Neste steg

Fullfør listen over Sikkerhet og testing.