Status, periodieke statusopvraging en betalingsafstemming

Query vanuit de 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 is optioneel en standaard true . Wealth Reader beperkt externe zoekopdrachten op basis van intentie; pas backoff ook toe op je backend en creëer geen nieuwe intentie zolang het resultaat ambigu is.

Drie verschillende dimensies

De enige positieve bevestiging is payment_status: settled, afgeleid van een expliciete bankstatus die de definitieve afwikkeling bevestigt. Een technisch resultaat DONE, interaction_status: completed of payment_status: pending komt nooit neer op een afwikkeling.

Dubbelzinnig resultaat

Een niet-herkende netwerkuitval, timeout of reactie na de start verandert de intentie naar reconciliation_required en stelt payment_status: unknownbloot. De start herhaalt zich niet automatisch.

De huidige provider biedt geen query aan die een initiatie reconstrueert waarvan het antwoord verloren is gegaan: de toestandsquery vereist de ondoorzichtige context die door diezelfde initiatie wordt teruggegeven. Daarom heeft dat geval handmatige afstemming nodig; het kan niet worden opgehaald door periodiek de automatische status te zoeken of door te zoeken naar de callback-ID.

In dat geval:

1. bewaar de identificatie en de idempotentiesleutel;
2. maak geen nieuwe betalingsintentie aan en autoriseer de betaling niet opnieuw;
3. Bekijk de geauthenticeerde status van Wealth Reader en behoud je veilige afstemmingsreferentie;
4. Neem contact op met technische ondersteuning; blijf de status niet controleren wanneer automatic_recovery false.

Voor een intentie die handmatige afstemming vereist, kan de server-naar-server query het volgende omvatten:

{
  "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"
  }
}

Deze identificaties zijn referenties voor ondersteuning waaruit gevoelige gegevens zijn verwijderd. Ze worden niet aan de widget geleverd en laten de klant niet toe de interne toestand van de aanbieder op te vragen of te reconstrueren.

reason is een Wealth Readercode, nooit de tekst van de leverancier. initiation_rejected geeft aan dat de leverancier heeft gereageerd met een definitieve afwijzing van de initiatie; initiation_response_unavailable, dat er geen herkenbare reactie was. In beide gevallen is de initiatie al verzonden, dus wordt deze niet herhaald: bewaar de referentie en neem contact op met de technische ondersteuning.

Terugroep en herhaling

De terugkeer na SCA bereikt een callback die uitsluitend voor betalingen is bestemd. Wealth Reader valideert de correlatie, stuurt de parameters van de bank ongewijzigd door naar de aanbieder (onverwachte parameternamen worden geregistreerd, maar leiden nooit tot afwijzing van een al geautoriseerde terugkeer), verwerkt de terugkeer slechts eenmaal en bewaart de gevoelige toestand versleuteld. Een herhaling retourneert uitsluitend HTTP 409; vertrouw niet op een interne foutcode in de responsebody.

Authenticatie kan meerdere redirects vereisen. Elke gevalideerde REDIRECT gaat door in hetzelfde SCA venster en opent een nieuw callbackcheckpoint; het creëert geen nieuwe initiatie. Een resultaat DECOUPLED houdt de intentie in processing zodat de widget naar status kan opvragen. Een expliciet RETRY herhaalt alleen de voltooiing die al is voorbereid, met een beperkte wachttijd en aantal pogingen. ERROR, PASSWORD, MORE_INFO, SELECT_OPTION, een onbekend resultaat of het uitputten van die limieten leidt tot afstemming, nooit in een nieuwe initiatie.

De handelaar hoeft deze callback niet te publiceren of te verwerken. Deze versie verstuurt geen webhooks naar de handelaar: de publieke bevestigingsinterface gebruikt periodieke server-to-server-statusopvragingen.

De widget sluiten

flow_closed geeft aan dat de zichtbare interactie is beëindigd. Het frontend kan het dialoogvenster sluiten, maar mag op basis van deze gebeurtenis niet aangeven dat de betaling is voldaan. De backend blijft verantwoordelijk voor het bevestigen of afstemmen van de betaling.

Volgende stap

Maak de lijst van compleet Beveiliging en testen.