Doel
Het doel is om te controleren of de integratie de volledige Pay. payment lifecycle correct afhandelt:
Configureren → Order aanmaken → Betaling verwerken → Status ontvangen → Merchant order bijwerken
De orderstatus binnen het merchantplatform moet altijd overeenkomen met de daadwerkelijke betaalstatus binnen Pay.
Let op: deze checklist is bedoeld als validatie- en certificatiehulpmiddel. Bij technische implementatievragen is de Developer Documentation altijd leidend.
1. Voordat je begint
Controleer voordat je met de certificering begint:
-
☐ Er is een test Sales location met geldige API-credentials beschikbaar.
-
☐ De integratie kan succesvol communiceren met de Pay. API.
-
☐ Er is minimaal één betaalmethode actief en beschikbaar om te testen.
-
☐ Transacties en merchant orders kunnen tijdens het testen worden gecontroleerd.
2. IntegratieconfiguratieAuthenticatie & Sales location
-
☐ API-authenticatie werkt correct en credentials worden veilig opgeslagen en niet blootgesteld aan de shopper/browser.
-
☐ De Sales location is configureerbaar en de juiste SL-code wordt gebruikt bij het aanmaken van orders.
-
☐ Test- en productieconfiguratie kunnen van elkaar worden gescheiden, zodat merchants veilig van omgeving/credentials kunnen wisselen zonder codewijzigingen.
Identificatie van de integratie
- ☐ De integratie identificeert zichzelf correct via stats.object, met waar van toepassing de naam en versie van de integratie/applicatie.
Waarom is dit belangrijk?
Correcte identificatie stelt Pay. in staat om te herkennen welke integratie een transactie heeft aangemaakt en helpt bij monitoring, support en troubleshooting.
3. Checkoutconfiguratie
Vul deze sectie in wanneer de integratie zelf de selectie van betaalmethoden of checkout opbouwt.
Betaalmethoden
-
☐ Beschikbare betaalmethoden zijn gebaseerd op de geconfigureerde Sales location en zijn niet permanent hard-coded.
Wijzigingen in geactiveerde betaalmethoden moeten kunnen worden doorgevoerd zonder dat hiervoor een nieuwe release van de integratie nodig is.
-
☐ Losse en gegroepeerde checkoutopties worden correct verwerkt, inclusief de betaalmethode of checkoutoptie die door de shopper wordt geselecteerd.
-
☐ Namen en beschikbare Pay. iconen/logo's van betaalmethoden worden correct weergegeven.
Configuratie van betaalmethoden
-
☐ Bedragslimieten van betaalmethoden worden gerespecteerd, inclusief het teruggegeven minimum- en maximumbedrag.
Een betaalmethode die het orderbedrag niet kan verwerken, zou niet als geldige optie moeten worden aangeboden of de shopper moet hierover duidelijke feedback krijgen.
-
☐ Verplichte velden van een checkoutoptie worden verzameld en correct meegestuurd bij het starten van de betaling.
-
☐ Betaalmethode-specifieke opties worden verwerkt wanneer van toepassing, op basis van de configuratie die Pay. teruggeeft.
Weergave van de checkout
-
☐ De checkoutvolgorde vanuit Pay. wordt gevolgd waar van toepassing, inclusief primary/secondary en landspecifieke volgordes.
-
☐ Vertalingen worden correct toegepast wanneer de integratie meerdere checkouttalen ondersteunt.
4. Order aanmaken
-
☐ Een order kan succesvol worden aangemaakt via de Pay. API met de geconfigureerde Sales location.
-
☐ Het bedrag en de valuta komen overeen met de merchant order en het bedrag wordt in het verwachte API-formaat verstuurd.
-
☐ De juiste betaalmethode of checkoutoptie wordt meegestuurd wanneer de shopper vooraf een keuze heeft gemaakt.
-
☐ De shopper wordt doorgestuurd via de payment/checkout URL die door Pay. wordt teruggegeven.
Merchant orderinformatie
-
☐ Elke Pay. order bevat een duidelijke merchant reference waarmee de transactie gekoppeld kan worden aan de bijbehorende order in het merchantplatform.
-
☐ Er wordt een duidelijke orderomschrijving meegestuurd.
-
☐ Relevante klant- en orderinformatie wordt meegestuurd wanneer beschikbaar, zoals klantgegevens, factuur-/verzendadres en winkelmandinformatie.
De integratie moet waar mogelijk daadwerkelijke merchantdata gebruiken in plaats van statische placeholderinformatie.
5. Betaling & statusverwerking
De Pay. betaalstatus moet bepalend zijn voor de status van de merchant order.
Alleen het terugkeren van de shopper naar de webshop mag nooit worden beschouwd als bewijs van een succesvolle betaling.
Statusverwerking
Controleer of de integratie de statussen die relevant zijn voor de ondersteunde betaalmethoden correct verwerkt:
-
☐ Succesvolle betalingen resulteren in de juiste betaalde/verwerkingsstatus van de merchant order.
-
☐ Pending betalingen blijven pending en starten geen fulfilment totdat een definitieve succesvolle status is ontvangen.
-
☐ Geannuleerde, verlopen, geweigerde en mislukte betalingen resulteren niet in een betaalde merchant order.
-
☐ Geautoriseerde betalingen worden afzonderlijk van betaalde/gecapturede betalingen verwerkt wanneer authorisation en capture worden ondersteund.
-
☐ Verification- en andere tussenstatussen leiden niet onterecht tot een betaalde merchant order.
-
☐ Latere statuswijzigingen worden correct verwerkt, zodat een order vanuit een tussenstatus naar de definitieve status kan worden bijgewerkt.
Terugkeer van de shopper
-
☐ De shopper wordt na het afronden of verlaten van de betaling correct teruggestuurd naar de merchantomgeving.
-
☐ De shopper krijgt passende feedback bij succesvolle, pending, geannuleerde of mislukte betalingen.
-
☐ Een nieuwe betaalpoging kan waar nodig veilig worden gestart zonder dat hierdoor onterecht een dubbele merchant order ontstaat.
6. Exchange-verwerking
Exchange calls zorgen ervoor dat wijzigingen in de betaalstatus het merchantplatform bereiken, onafhankelijk van de browser van de shopper.
Exchange endpoint
-
☐ Er is een geldige en publiek bereikbare Exchange URL geconfigureerd.
-
☐ Exchange calls kunnen zonder actieve shoppersessie worden verwerkt.
-
☐ De Pay. order kan aan de juiste merchant order worden gekoppeld en de ontvangen status werkt deze order correct bij.
-
☐ Het endpoint geeft een succesvolle response nadat de Exchange is verwerkt.
Betrouwbaarheid
-
☐ Exchange-verwerking is idempotent.
Het meerdere keren ontvangen van dezelfde Exchange mag niet leiden tot dubbele orders, dubbele fulfilment of dubbele financiële acties.
-
☐ De integratie is niet afhankelijk van het terugkeren van de shopper naar de webshop.
Het sluiten van de browser na de betaling mag niet voorkomen dat de merchant order uiteindelijk de juiste status ontvangt.
-
☐ Tijdelijke fouten bij Exchange-verwerking kunnen correct worden hersteld wanneer de Exchange opnieuw wordt aangeboden.
7. Transactiemanagement
Vul alleen de onderdelen in die door de integratie worden ondersteund.
Refunds
-
☐ Volledige refunds kunnen correct worden uitgevoerd en zijn gekoppeld aan de juiste Pay. transactie.
-
☐ Gedeeltelijke refunds worden correct verwerkt wanneer deze worden ondersteund, inclusief meerdere gedeeltelijke refunds zonder het beschikbare refundbedrag te overschrijden.
-
☐ De refundstatus wordt correct verwerkt in het merchantplatform.
Authorisation & capture
Indien ondersteund:
-
☐ Geautoriseerde transacties kunnen correct worden gecaptured.
-
☐ Partial capture werkt correct wanneer dit wordt ondersteund.
-
☐ Een authorisation kan correct worden gevoid/geannuleerd wanneer dit wordt ondersteund.
8. Foutafhandeling & supportability
-
☐ API-fouten worden correct afgehandeld zonder dat de merchant order hierdoor onterecht als voltooid wordt beschouwd.
-
☐ Het opnieuw proberen van een mislukte of onzekere betaalrequest veroorzaakt niet onnodig dubbele merchant orders of betalingen.
-
☐ Payment- en Exchange-fouten worden voldoende gelogd voor troubleshooting.
-
☐ Een transactie kan worden teruggevonden via zowel de Pay. order ID als de merchant reference.
-
☐ API-credentials en andere secrets worden niet in logs opgeslagen.
9. Certificeringstestscenario's
Demonstreer tijdens de certificering minimaal de scenario's die van toepassing zijn op de integratie:
-
☐ Succesvolle betaling
-
☐ Geannuleerde betaling
-
☐ Mislukte betaling
-
☐ Pending → succesvolle betaling
-
☐ Shopper sluit de browser voordat deze terugkeert naar de merchant
-
☐ Tweede betaalpoging na annulering/mislukte betaling
-
☐ Dubbele Exchange delivery
-
☐ Tijdelijke API- of Exchange-fout
-
☐ Minimum-/maximumbedrag van een betaalmethode, waar van toepassing
-
☐ Volledige refund, indien ondersteund
-
☐ Gedeeltelijke refund, indien ondersteund
-
☐ Authorisation/capture/void, indien ondersteund
Betaalmethoden met wezenlijk verschillende betaalflows moeten afzonderlijk worden getest.
10. Bewijs voor certificering
Lever het volgende aan bij jouw Integration Manager.
-
☐ Naam en versie van de integratie/applicatie
-
☐ stats.object waarde
-
☐ Test Sales location ID
-
☐ Pay. order ID en merchant reference van een succesvolle betaling
-
☐ Pay. order ID van een geannuleerde/mislukte betaling
-
☐ Voorbeeld van een pending betaling, waar van toepassing
-
☐ Bewijs dat een Exchange de merchant order correct bijwerkt
-
☐ Refundtransactie wanneer refunds worden ondersteund
-
☐ Overzicht van ondersteunde betaalmethoden en transactiemanagementfunctionaliteiten
-
☐ Eventuele bekende beperkingen of functionaliteiten die bewust niet worden ondersteund
Certificering voltooid
De integratie is gereed voor goedkeuring wanneer alle toepasselijke vereisten zijn gevalideerd en de vereiste testscenario's succesvol zijn aangetoond.
Onderdelen die als niet van toepassing worden aangemerkt, moeten overeenkomen met functionaliteiten die de integratie niet aanbiedt.