In dit Verkooplocatie menu kunt u de instellingen voor de Exchange-integratie configureren. U geeft aan of u een dynamische of statische Exchange-URL wilt gebruiken, selecteert de methode van aanroepen (zoals TXT, XML, JSON), stelt een scheidingsteken in en kiest een retry-scheme voor het opnieuw proberen van mislukte aanroepen. Daarnaast bepaalt u welke statusupdates via de Exchange gecommuniceerd moeten worden, bijvoorbeeld alle statussen, alleen betaalde orders of alleen wijzigingen in orderstatussen.
| Instelling | Waarde |
|---|---|
| Exchange instellen |
|
| Exchange URL | Url: https:// |
| Methode van aanroepen |
|
| Separator |
|
| Retry scheme |
|
| Status communicatie |
|
Signed JSON POST heeft de voorkeur
De Signed JSON heeft de voorkeur, omdat deze alle benodigde data bevat. Hierdoor is er geen aanvullende API-call nodig. De authenticiteit en integriteit van de data kunnen direct worden gevalideerd aan de hand van de meegeleverde headers. Ook IP whitelisting is hierbij niet noodzakelijk.
Lees er meer over op onze developer portal in het Exchange Signing artikel
Retry scheme Intervallen
Het Retry-scheme herhaalt een mislukte Exchange-aanroep volgens vooraf ingestelde intervallen totdat de server “TRUE” terugstuurt. Hiermee wordt bevestigd dat het verzoek succesvol is verwerkt. Door gebruik te maken van verschillende intervallen tussen de herhalingen wordt overbelasting van de server voorkomen en wordt de kans vergroot dat een tijdelijk probleem wordt opgelost voordat het verzoek opnieuw wordt geprobeerd.
| Retry moment | 10x / 24u (oplopend) | 11x / 24u (gebalanceerd) | 8x / kwartier | 6x / 2u | 1x / 5s |
|---|---|---|---|---|---|
| 1e retry na: | 1 seconde | 10 seconden | 15 minuten | 30 seconden | 5 seconden |
| 2e retry na: | 3 seconden | 30 seconden | 30 minuten | 50 seconden | - |
| 3e retry na: | 10 seconden | 1 minuut | 45 minuten | 70 seconden | - |
| 4e retry na: | 30 seconden | 2 minuten | 60 minuten | 5 minuten | - |
| 5e retry na: | 60 seconden | 1 uur | 75 minuten | 30 minuten | - |
| 6e retry na: | 5 minuten | 3 uren | 90 minuten | 60 minuten | - |
| 7e retry na: | 30 minuten | 6 uren | 105 minuten | - | - |
| 8e retry na: | 60 minuten | 10 uren | 120 minuten | - | - |
| 9e retry na: | 12 uren | 14 uren | - | - | - |
| 10e retry na: | 24 uren | 19 uren | - | - | - |
| 11e retry na: | - | 24 uren | - | - | - |
Wanneer is een exchange geslaagd?
Een Exchange-aanroep wordt als geslaagd beschouwd wanneer de server TRUE retourneert én de HTTP-statuscode 200 is. Wanneer niet aan beide voorwaarden wordt voldaan, wordt de Exchange-aanroep als mislukt beschouwd en volgt het ingestelde retry-scheme
Het Retry-scheme herhaalt een mislukte Exchange-aanroep volgens vooraf ingestelde intervallen bij het mislukken. Hiermee wordt bevestigd dat het verzoek succesvol is verwerkt. Door gebruik te maken van verschillende intervallen tussen de herhalingen wordt overbelasting van de server voorkomen en wordt de kans vergroot dat een tijdelijk probleem wordt opgelost voordat het verzoek opnieuw wordt geprobeerd.
Status Communicatie
Met statuscommunicatie bepaalt u zelf welke transactiestatussen naar de Exchange-URL worden doorgestuurd. Zo ontvangt u alleen relevante meldingen, voorkomt u onnodige notificaties en kunt u uw workflows efficiënter aansturen.
| Type | Actie | Code | All | Payment complete only | Order change |
Changes no pending |
|---|---|---|---|---|---|---|
|
Pending status |
pending | 20 | ✔ | ✖ | ✖ | ✖ |
| pending | 25 | ✔ | ✖ | ✖ | ✖ | |
| pending | 50 | ✔ | ✖ | ✖ | ✖ | |
| pending | 90 | ✔ | ✖ | ✖ | ✖ | |
| Order change | new_ppt | 100 | ✔ | ✔ | ✔ | ✔ |
| cancel | -90 | ✔ | ✖ | ✔ | ✔ | |
| cancel | -80 | ✔ | ✖ | ✔ | ✔ | |
| authorize | 95 | ✔ | ✖ | ✔ | ✔ | |
| capture | 100 | ✔ | ✔ | ✔ | ✔ | |
| refunding | -72 | ✔ | ✖ | ✔ | ✔ | |
| refunded | -81 | ✔ | ✔ | ✔ | ✔ | |
| denied | -63 | ✔ | ✖ | ✔ | ✔ | |
| denied | -64 | ✔ | ✖ | ✔ | ✔ | |
| failure | -60 | ✔ | ✖ | ✔ | ✔ | |
| verify | 85 | ✔ | ✖ | ✔ | ✔ | |
| chargeback | -71 | ✔ | ✖ | ✔ | ✔ | |
| chargeback reversal | 100 | ✔ | ✔ | ✔ | ✔ | |
| Mutatie (actie) | refund:add | -72 | ✔ | ✖ | ✔ | ✔ |
| refund:delete | 100 | ✔ | ✔ | ✔ | ✔ | |
| refund:received | -81 | ✔ | ✔ | ✔ | ✔ | |
| refund:storno | 100 | ✔ | ✔ | ✔ | ✔ | |
| incasso:add | 50 | ✔ | ✖ | ✔ | ✖ | |
| incassocollected | 100 | ✔ | ✔ | ✔ | ✔ | |
| incasso:deleted | ✔ | ✖ | ✔ | ✔ | ||
| incassostorno | -63 | ✔ | ✖ | ✔ | ✔ |
Mislukte Exchange Notificatie
Als Pay. na een statuswijziging jouw Exchange URL aanroept, dan wordt er maximaal 5 seconden gewacht op een antwoord. Het kan echter voorkomen dat jouw server tijdelijk niet reageert of een storing ervaart.
Wij sturen dan als de herhalingen van de Retry scheme zijn afgerond een Mislukte Exchange Notificatie per e-mail naar alle merchant gebruikers die deze E-mail Notificatie hebben ingeschakeld in hun persoonlijke account.
Exchange-call mislukt of duurt te lang (> 5 seconden)
Wanneer een Exchange-call langer dan 5 seconden duurt, verbreken wij de verbinding en beschouwen we het verzoek als mislukt. Dit betekent echter niet automatisch dat de verwerking op jouw server ook is gestopt.
Het kan daardoor voorkomen dat jouw server een statuswijziging niet of niet correct heeft verwerkt. In bepaalde gevallen kan de orderstatus in jouw eigen backoffice hierdoor afwijken van de status in het Admin Panel van Pay.
Controleer de accesslog
Controleer eerst in de accesslog hoe lang de Exchange-call daadwerkelijk heeft geduurd. Hiermee kun je bepalen of de vertraging ontstaat in het netwerk of tijdens de verwerking op jouw server. In de meeste gevallen zit de vertraging in de verwerking zelf.
Bijvoorbeeld:
2026-08-19T10:17:32.481+02:00 INFO access exchange=payment-api method=POST path=/v1/paynl/exchange status=200 duration=7000ms remote_ip=10.20.30.40
In dit voorbeeld heeft de verwerking 7000 ms (7 seconden) geduurd en daarmee de maximale responstijd van 5 seconden overschreden.
Onderzoek het Exchange-proces
Als uit de accesslog blijkt dat de verwerking te lang duurt, onderzoek dan welke onderdelen van jouw backend hiervoor verantwoordelijk zijn. Hiervoor is voldoende logging rondom de verschillende stappen van het Exchange-proces belangrijk.
Veelvoorkomende oorzaken van trage Exchange-calls zijn:
- Trage databasequeries
- Het genereren van PDF-bestanden of e-mails
- Trage externe API-calls
- Overbelaste servers
- Een cold start van een service
Let op: wanneer Pay de verbinding na 5 seconden verbreekt, betekent dit niet dat het proces op jouw server automatisch wordt beëindigd. De backend kan de verwerking alsnog afronden. Houd hier rekening mee om dubbele of inconsistente verwerking te voorkomen.
Probeer werkzaamheden die niet noodzakelijk zijn voor het verwerken van de Exchange-call waar mogelijk asynchroon uit te voeren. Geef eerst zo snel mogelijk een succesvolle response terug en voer bijvoorbeeld e-mail- of PDF-generatie daarna uit.
Overige foutoplossingen
In de Payment state log vind je o.a de HTTP Code terug. Indien deze niet de waarde 200 heeft dan is er een fout opgetreden. Via deze Online checklist kun je achterhalen hoe je de meest voorkomende problemen kan oplossen.
Ontvang je op dit moment Exchangenotificaties en wil je deze uitschakelen? Vraag dan jouw Pay. beheerder om deze uit te schakelen in het Pay Dashboard. Dit kan via Instellingen -> Gebruikersbeheer
Kan ik een langere Exchange-timeout aanvragen?
Ja, het is mogelijk om een langere timeout voor Exchange-calls aan te vragen. We raden dit echter niet aan.
De standaard timeout is bewust kort gehouden. Een Exchange-call is bedoeld om een statuswijziging snel te verwerken en een response terug te geven. Wanneer jouw Exchange-endpoint regelmatig de timeout overschrijdt, is het daarom beter om eerst te onderzoeken waarom de verwerking zoveel tijd kost.
Payment state log
Exchange verzoeken via Payment state log
Exchange verzoeken via Payment state log
De Payment state log is een tabel met daarin alle exchange calls tussen Pay. en de server van jouw (webshop) implementatie van de afgelopen 35 dagen. Het is niet mogelijk om exchange calls ouder dan 35 dagen op te vragen.
Mislukte Exchange calls opvragen
Volg de onderstaande stappen om de Exchange calls op te vragen.
-
Ga naar My.pay.nl
-
Klik op het tabblad Rapportages en vervolgens op het tabblad Payment state log.
-
Activeer het filter en kies bijvoorbeeld de Filter type Status is gelijk aan Mislukt en klik op Gegevens ophalen.
-
Het rapport laat nu alle calls met de status mislukt zien.
-
Klik op een regel in de tabel of op het Details icoon aan de rechterkant van de regel om één mislukte Externe call op te vragen
-
Klik op Nogmaals aanroepen om deze enkele call opnieuw aan te roepen.
Meerdere mislukte Exchange Calls tegelijk aanroepen
-
Ga naar My.pay.nl
-
Klik op het tabblad Rapportages en vervolgens op het tabblad Payment state log.
-
Klik rechts bovenin het overzicht (naast het vraagteken icoon) op het Configuratie icoon. Scroll naar beneden en zet het veld Resultaten per pagina op het gewenst aantal Exchange Calls (500 is het limiet)
-
Activeer het filter en kies de Filter type Status is gelijk aan Mislukt en klik op Gegevens ophalen.
-
Het rapport laat nu alle calls met de status mislukt zien. Vink alle calls aan in de tabel header
-
Klik links onderin de Payment State Log op de dropdown en kies Nogmaals aanroepen en klik op OK
-
Herhaal dit totdat alle mislukte calls zijn weggewerkt