14 okt 2025·8 min
Apple Pay in mobiele apps: wat het is en hoe het werkt
Leer wat Apple Pay in mobiele apps is, hoe het achter de schermen werkt en hoe je het veilig integreert om het afrekenen te versnellen en de conversie te verbeteren.
Leer wat Apple Pay in mobiele apps is, hoe het achter de schermen werkt en hoe je het veilig integreert om het afrekenen te versnellen en de conversie te verbeteren.
Apple Pay is Apple’s digitale portemonnee en betaalservice. Hiermee kunnen gebruikers creditcards, debetkaarten en sommige prepaid- en winkelkaarten veilig op hun iPhone, Apple Watch, iPad of Mac opslaan en betalen met één tik of blik.
In plaats van kaartnummers en factuurgegevens in te voeren, verifieert de gebruiker zich met Face ID, Touch ID of een apparaat-toegangscode. Apple genereert een apparaat-specifiek token zodat het echte kaartnummer niet met de merchant wordt gedeeld.
Apple Pay werkt in drie hoofdcontexten:
Deze gids richt zich op in-app Apple Pay, waarbij de hele betaalervaring binnen de app blijft.
Kaartgegevens intypen op een klein scherm is traag en foutgevoelig. Apple Pay vervangt meerdere formuliervelden door één handeling, wat doorgaans:
Omdat kaarten en adressen al op het apparaat zijn opgeslagen, verlaagt Apple Pay ook de frictie voor nieuwe klanten.
Apple Pay werkt op recente iPhone-, iPad-, Apple Watch- en Mac-modellen in ondersteunde regio’s, met grote netwerken zoals Visa, Mastercard en American Express, en vaak ook lokale schema’s, afhankelijk van de uitgevende bank.
Apple Pay is het meest geschikt wanneer:
Het moet naast traditionele kaartformulieren en andere wallets bestaan, niet volledig in plaats van hen, zodat gebruikers zonder Apple Pay nog steeds kunnen betalen.
Apple Pay verbergt veel complexiteit achter een eenvoudige “dubbelklik om te betalen”-ervaring. Onder de motorkap coördineren meerdere partijen en beveiligingslagen om geld veilig te verplaatsen.
Een typische Apple Pay-transactie omvat:
Wanneer een gebruiker een kaart toevoegt aan Apple Wallet, wordt het echte kaartnummer (de FPAN, of Funding Primary Account Number) veilig naar het kaartnetwerk en de issuer gestuurd. Zij antwoorden met een DPAN (Device Primary Account Number) plus cryptografische sleutels uniek voor dat apparaat.
De DPAN is wat Apple Pay tijdens transacties gebruikt. Jouw app en backend zien nooit de FPAN. Dit is de kern van Apple Pay’s tokenisatiemodel: het apparaat gebruikt een surrogaatkaartnummer en eenmalige cryptogrammen in plaats van het echte kaartnummer bloot te geven.
Op ondersteunde apparaten wonen betalingsreferenties en sleutels in het Secure Element (of zijn beschermd via de Secure Enclave). Wanneer de gebruiker zich verifieert (Face ID, Touch ID of toegangscode), doet het Secure Element het volgende:
Je app ontvangt dit ondoorzichtige, versleutelde token via Apple Pay-API’s en stuurt het naar je backend, die het doorstuurt naar de PSP of gateway.
De PSP ontsleutelt het token, extraheert DPAN en cryptogram en dient een authorisatieaanvraag in via het kaartnetwerk naar de uitgevende bank. De issuer valideert het cryptogram en de kaartstatus en keurt goed of wijst af.
Later, tijdens de settlement, wordt het geautoriseerde bedrag gecaptured, gebatched en verplaatst van de uitgevende bank naar de acquiring bank van de merchant. Voor jouw app is dit gewoon het afhandelen van een capture of sale, maar achter de schermen is het een coördinatie tussen acquirer, kaartnetwerk en issuer met gebruik van de DPAN — niet het echte kaartnummer van de klant.
Voordat je Apple Pay aan je app toevoegt, moet je een reeks technische, zakelijke en regionale vereisten vervullen.
Aan de merchant-kant moet je hebben:
Veel merchants maken ook een Merchant Identity-certificate voor merchant-validatie tijdens webgebaseerde of hybride flows.
Apple Pay in apps wordt ondersteund op:
Controleer Apple’s actuele documentatie voor minimale OS-ondersteuning, vooral als je op nieuwere API’s vertrouwt.
Apple Pay is niet in elk land of bij elke bank beschikbaar. Je moet bevestigen:
Apple kan bepaalde merchantcategorieën en use-cases beperken (bijv. illegale goederen, sommige digitale content of diensten, risicovolle industrieën). Controleer dat:
Tot slot heb je een PSP of payment gateway nodig die Apple Pay-tokenisatie en ontsleuteling ondersteunt. Bevestig dat je provider:
Een vloeiende Apple Pay-flow voelt bijna onzichtbaar voor de gebruiker. Hieronder staat wat er meestal gebeurt, stap voor stap.
De reis begint meestal op een productpagina of winkelwagen. Zodra de gebruiker items en opties heeft gekozen (maat, kleur, aantal), gaan ze naar de checkout.
Op het checkout- of winkelwagenscherm toon je de standaard Apple Pay-knop die Apple levert. Deze moet:
Wanneer de gebruiker op de knop tikt, schuift de Apple Pay-sheet van onderin het scherm omhoog.
Dit sheet bevat meestal:
De gebruiker kan details (kaart, verzending, contact) direct in het sheet aanpassen voordat hij bevestigt.
Om de betaling te autoriseren, verifieert de gebruiker met:
Het sheet geeft duidelijk een prompt weer, bijvoorbeeld: “Dubbelklik om te betalen” op Face ID-apparaten.
Na authenticatie toont het sheet voortgang en verdwijnt het, waarna de gebruiker terugkeert naar je app.
Je app moet meteen een duidelijke status tonen:
Duidelijke en consistente statussen geven gebruikers vertrouwen dat de betalingsstatus eenduidig is en dat zij de controle houden over de flow.
Het implementeren van Apple Pay op iOS draait om het PassKit-framework en enkele sleutelklassen. Hieronder staat de end-to-end flow op app-niveau.
Dit koppelt je app-bundle aan je merchant-identity zodat Apple Pay-tokens voor je server gegenereerd kunnen worden.
PKPaymentRequestimport PassKit
func createPaymentRequest() -> PKPaymentRequest? {
guard PKPaymentAuthorizationController.canMakePayments() else { return nil }
let request = PKPaymentRequest()
request.merchantIdentifier = "merchant.com.yourcompany.app"
request.countryCode = "US"
request.currencyCode = "USD"
request.supportedNetworks = [.visa, .masterCard, .amex]
request.merchantCapabilities = [.capability3DS]
request.paymentSummaryItems = [
PKPaymentSummaryItem(label: "Pro Subscription", amount: 9.99),
PKPaymentSummaryItem(label: "Your Company", amount: 9.99)
]
return request
}
merchantIdentifier, countryCode en currencyCode moeten overeenkomen met je merchant-setup. supportedNetworks weerspiegelt de kaartschema’s die jij en je PSP ondersteunen. Neem minimaal .capability3DS op in merchantCapabilities.
PKPaymentButtonGebruik PKPaymentButton in plaats van aangepaste knoppen zodat je aan Apple’s UI-richtlijnen voldoet:
let payButton = PKPaymentButton(paymentButtonType: .buy, paymentButtonStyle: .black)
Plaats de knop waar de koopintentie het sterkst is: productscherm, winkelwagen en definitieve checkout. Schakel hem uit of verberg hem als PKPaymentAuthorizationController.canMakePayments() false retourneert.
PKPaymentAuthorizationController en verwerk callbacksCreëer een controller van het request en implementeer PKPaymentAuthorizationControllerDelegate:
func startApplePay() {
guard let request = createPaymentRequest() else { return }
let controller = PKPaymentAuthorizationController(paymentRequest: request)
controller.delegate = self
controller.present(completion: nil)
}
extension CheckoutViewController: PKPaymentAuthorizationControllerDelegate {
func paymentAuthorizationController(_ controller: PKPaymentAuthorizationController,
didAuthorizePayment payment: PKPayment,
handler completion: @escaping (PKPaymentAuthorizationResult) -> Void) {
// Send payment.token to your server for processing
// Then call completion(.init(status: .success, errors: nil)) or .failure
}
func paymentAuthorizationControllerDidFinish(_ controller: PKPaymentAuthorizationController) {
controller.dismiss(completion: nil)
}
}
In didAuthorizePayment stuur je payment.token naar je server voor daadwerkelijke afhandeling. Nadat je server heeft geantwoord, roep je .success of .failure aan en sluit je het sheet in paymentAuthorizationControllerDidFinish.
Server-side logica zet een Apple Pay-sheet om in echte geldbeweging. De app verzamelt gebruikersautorisatie; je backend valideert de merchant, verwerkt het token en communiceert met je payment gateway.
Voordat je het Apple Pay-sheet toont, moet je app een merchant session van Apple verkrijgen.
PKPaymentAuthorizationController levert.Deze flow bewijst aan Apple dat de app is gekoppeld aan je merchant-identity en domein.
Nadat de gebruiker de betaling autoriseert, ontvangt de app een versleuteld payment token (PKPaymentToken) en stuurt dat via HTTPS naar je backend.
Op de server:
De gateway ontsleutelt het token (met netwerk-tokens of DPANs) en voert de kaartautorisatie uit met de kaartnetwerken.
Gateways bieden meestal twee flows:
Je backend moet het transactie-ID van de gateway, bedrag, valuta en status persistent opslaan — maar nooit ruwe kaartgegevens of ontsleutelde tokeninhoud.
Bewaar alleen wat je echt nodig hebt voor reconciliatie, refunds en klantenservice:
Bewaar nooit volledige kaartnummers, CVV of onversleutelde payment tokens op je eigen servers. Schuif gevoelige verwerking naar PCI-compliant gateways en zorg dat alle communicatie over TLS verloopt met strikte logging- en toegangscontroles.
Apple Pay is ontworpen zodat je app nooit ruwe kaartnummers aanraakt, maar je moet het beveiligingsmodel en je verantwoordelijkheden begrijpen.
Wanneer een gebruiker een kaart toevoegt aan Apple Pay, vervangen de issuer en het netwerk het echte PAN (kaartnummer) door een Device Account Number (DAN).
Tijdens een betaling:
Je app en backend zien alleen tokens en transactie-metadata, niet de onderliggende kaartgegevens.
Gevoelige sleutels en betalingsreferenties worden opgeslagen en verwerkt in de Secure Enclave, een hardware-geïsoleerde coprocessor.
Autorisatie is gekoppeld aan gebruikersverificatie:
Je app ontvangt alleen een succes- of faalsignaal van het systeemsheet; het krijgt nooit toegang tot biometrische data of Secure Enclave-inhoud.
Elke Apple Pay-transactie gebruikt:
Netwerken en issuers valideren deze waarden, wat helpt bij het detecteren van klonen, replay en manipulatie.
Apple Pay kan de PCI DSS-scope van je app aanzienlijk verkleinen omdat:
Toch:
Voor formele guidance raadpleeg je je acquirer, PSP en een gekwalificeerde security assessor.
Apple Pay vermindert risico’s, maar slordige integraties kunnen blootstelling opnieuw introduceren.
Praktische tips:
Door deze grenzen te respecteren benut je Apple Pay’s ingebouwde bescherming terwijl je je eigen compliancelast beheersbaar houdt.
Grondig testen is de enige manier om vertrouwen te hebben in je Apple Pay-integratie. Dat begint met een goede sandbox-setup en een duidelijk testplan.
Maak in je Apple Developer / App Store Connect-account sandbox tester-accounts aan onder Users and Access → Sandbox. Deze speciale Apple ID’s gebruik je op testapparaten om echte betalingen te simuleren zonder echte afschrijvingen.
Op je testapparaten:
Gebruik aparte sandbox-testers voor verschillende gebruikersprofielen (regio’s, valuta’s, kaartnetwerken) om edge-cases reproduceerbaar te maken.
De iOS Simulator ondersteunt basis Apple Pay-testing, wat handig is voor snelle UI-validatie en vroege ontwikkeling. Je kunt autorisaties simuleren en controleren of je PKPaymentAuthorizationController-flow werkt.
Valideer echter altijd op fysieke apparaten, omdat alleen die:
Behandel de Simulator als een hulpmiddel, niet als vervanger.
Test in elk geval de volgende flows end-to-end (client en server):
Gebruik gateway-specifieke testkaarten en triggers om declines en foutcodes af te dwingen.
Log genoeg om problemen te traceren, maar log nooit gevoelige betalingsdata. Vermijd:
Log in plaats daarvan:
created → authorized → captured → failed)Koppel clientlogs en serverlogs via een gedeelde correlation ID die van app naar backend wordt gestuurd.
Let tijdens testcycli op:
Als je intermitterende fouten of langzame autorisaties ziet, controleer eerst de status van je gateway en Apple voordat je ervan uitgaat dat het een integratiefout is. Dat bespaart tijd.
Doordachte Apple Pay-designs kunnen van een "nice-to-have" een belangrijke conversiedriver maken. Kleine beslissingen over plaatsing en tekst hebben grote impact op gebruik.
Gebruik Apple Pay waar de koopintentie sterk is:
Vermijd het verbergen van Apple Pay achter extra tikken zoals “Meer betaalopties”. Elke extra stap verlaagt het gebruik.
Bied Apple Pay als express checkout vanaf:
Als express checkout wordt gebruikt, maak dan duidelijk dat verzending en contactgegevens tijdens Apple Pay-autorisatie worden afgehandeld.
Volg Apple’s Human Interface Guidelines:
Vermijd aangepaste kleuren of iconen die herkenning verminderen of merkrichtlijnen schenden.
Laat Apple Pay het werk doen:
Het doel is een enkele beslissende tik, geen meerledige funnel.
De snelste manier om een verkoop te verliezen is een verwarrende fouttoestand. Plan voor fouten met:
Log foutdetails stil voor je team, maar toon gebruikers alleen wat ze moeten weten en hoe ze verder kunnen.
De meeste Apple Pay-problemen ontstaan door verkeerde configuratie.
Controleer eerst of de merchant ID in code exact overeenkomt met die in het Apple Developer-account en in je payment gateway-instellingen. Een enkele tekenfout (of een sandbox-merchant ID in productie) zal de flow breken.
Verifieer vervolgens entitlements en capabilities:
Als Apple Pay-knoppen niet verschijnen of het sheet nooit opent, is configuratie doorgaans de belangrijkste verdachte.
Apple Pay kan in sommige landen, bij bepaalde issuers of op bepaalde apparaten beschikbaar zijn en elders niet.
Gebruik PKPaymentAuthorizationController.canMakePayments() en canMakePayments(usingNetworks:) voordat je de Apple Pay-knop toont. Als ze false teruggeven, verberg de knop en geef een duidelijke uitleg en alternatieve betaalmethode.
Als gebruikers melden dat kaarten “niet worden ondersteund”, controleer dan:
Merchant-validatiefouten tonen zich vaak doordat het Apple Pay-sheet snel verdwijnt of nooit verschijnt.
Voor native apps worden ze meestal veroorzaakt door:
Log op de server of validatie-endpoint:
Deze logs wijzen meestal direct op het verkeerd geconfigureerde element.
Niet elke fout is technisch; veel zijn issuer declines.
Inspecteer altijd de gateway- of processorrespons. Onderscheid tussen:
Map deze categorieën naar gebruiksvriendelijke meldingen zoals:
Vermijd het tonen van rauwe gateway-foutcodes of onnodige technische details.
Investeer in gestructureerde logging rond elke betalingspoging:
Stel dashboards en alerts in voor pieken in declines, merchant-validatiefouten of timeouts. Koppel client-events aan serverlogs om snel te traceren waar fouten optreden.
Deze observability verkort de debuggingtijd aanzienlijk wanneer problemen in live verkeer opduiken.
Als Apple Pay live is in je mobiele app, moet je aantonen dat het de checkout daadwerkelijk verbetert. Dat betekent de juiste events volgen, kernmetrics monitoren en gestructureerde experimenten uitvoeren.
Begin met een heldere funnel en log events op elk punt:
Korelëer deze events met context:
Zo zie je waar gebruikers afhaken en of problemen UX-gerelateerd (annuleringen), technisch (autorisatiefouten) of backend-gerelateerd (capture-fouten) zijn.
Een gefocuste set metrics maakt het makkelijker om impact te beoordelen:
Volg deze over tijd en over app-releases om te zien of integratie- en UX-wijzigingen effect hebben.
Voer experimenten uit om Apple Pay te optimaliseren:
Meet verschillen in adoptie, succesratio, time to pay en conversie. Zelfs kleine lay-outwijzigingen kunnen significante verbeteringen opleveren.
Integreer analytics zorgvuldig zodat je Apple Pay’s privacygaranties en regelgeving respecteert:
Grote analytics-platforms kunnen deze Apple Pay-events verwerken zolang je payloads vrij zijn van gevoelige betalingsdetails.
Inzichten uit Apple Pay reiken verder dan die ene knop:
Na verloop van tijd helpen deze metrieken je niet alleen Apple Pay te verbeteren, maar de hele checkout-ervaring sneller, duidelijker en betrouwbaarder te maken.
Ondersteuning van Apple Pay stopt zelden bij één iOS-app. Gebruikers verwachten consistente betaalopties over apparaten en kanalen, en je keuzes moeten daarop aansluiten.
Native apps gebruiken PKPaymentAuthorizationController en sturen payment tokens direct naar je backend. Dit biedt:
Apple Pay op het web (Safari) gebruikt JavaScript en de Payment Request API. Dit is ideaal wanneer je:
Voor veel teams is de beste aanpak: native Apple Pay in de app, Apple Pay op het web in Safari, met een gedeelde backend-betaalpipeline.
Als je ook Google Pay, PayPal of soortgelijke wallets ondersteunt, stem dan de high-level flow op elkaar af:
Zo voelt het wisselen tussen apparaten of betaalmethoden niet als het leren van een nieuw systeem.
Voor React Native, Flutter en vergelijkbare frameworks vertrouw je meestal op:
Test op iPhone, iPad en Apple Watch waar relevant:
Streef naar een enkel designsystem en checkoutlogica die iOS, web en andere platformen beslaat, met dunne integratielagen per kanaal in plaats van aparte implementaties.
Het gezond houden van Apple Pay draait minder om grote herschrijvingen en meer om gedisciplineerd onderhoud.
Apple Pay vertrouwt op merchant IDs en payment processing-certificaten die verlopen.
Maak een eigendomskartering: wie heeft het Apple Developer-account, waar liggen certificaten en hoe worden ze gebruikt in CI/CD en op servers?
Vervolgens:
Elke grote iOS-release moet een testcyclus voor Apple Pay-flows triggeren op beta- en finalebuilds. Focus op:
Houd in de gaten:
Plan minstens jaarlijks een designreview om wording, knopplaatsing en toegankelijkheid te alignen met de laatste richtlijnen.
Kaartnetwerken, valuta’s en ondersteunde regio’s veranderen in de tijd. Houd ze configureerbaar:
Coördineer met je gateway wanneer zij netwerken of lokale methoden toevoegen en update je PKPaymentRequest dienovereenkomstig.
Voor gateway-wijzigingen, app-herstructureringen of tokenformat-updates:
Documenteer deze flows zodat nieuwe teamleden ze kunnen onderhouden zonder reverse-engineering.
Verwacht diepere tokenisatie met netwerken, rijkere ontvangstbewijzen en order-updates in Wallet, en strakkere koppelingen tussen in-app, web en in-store Apple Pay. Functies zoals Tap to Pay on iPhone en regionale financieringsopties blijven uitbreiden, dus ontwerp je integratie config-driven en klaar om nieuwe mogelijkheden te adopteren zonder de kernflow te herschrijven.
Apple Pay is Apple’s digitale portemonnee waarmee gebruikers betalen met kaarten die op hun iPhone, iPad, Apple Watch of Mac zijn opgeslagen.
In mobiele apps vervangt het het handmatig invoeren van kaartgegevens door een beveiligd systeemvenster waarin gebruikers de betaling bevestigen met Face ID, Touch ID of hun toegangscode. De app ontvangt een versleuteld betalingstoken in plaats van ruwe kaartgegevens, dat naar je backend en betalinggateway wordt gestuurd om de betaling te voltooien.
Dit maakt het afrekenen sneller, vermindert fouten en houdt kaartnummers buiten je app-infrastructuur.
Je moet Apple Pay toevoegen wanneer:
Apple Pay werkt het beste als een aanvullende optie naast kaarten, PayPal, enz. Verwijder andere betaalmethoden niet; bied Apple Pay aan als het snelste pad voor geschikte gebruikers.
Minimaal heb je nodig:
Op iOS doe je globaal het volgende:
Het apparaat creëert een versleuteld betalingstoken dat bevat:
Dit token is versleuteld voor je payment processor, dus je app en backend behandelen het als een ondoorzichtig blob. Je backend stuurt het door naar de gateway, die het ontsleutelt, een autorisatieaanvraag naar het kaartnetwerk en de issuer stuurt en vervolgens succes of mislukking teruggeeft.
Je ziet nooit de daadwerkelijke PAN of cryptografische sleutels; alleen transactie-metadata en status.
Je backend moet:
Probeer tokens niet zelf te ontsleutelen of langdurig op te slaan. Laat je PCI-gecertificeerde gateway al het gevoelige kaartverkeer afhandelen.
Veelvoorkomende oorzaken zijn:
Controleer eerst configuratie in het Apple Developer-portaal, Xcode-entitlements en gateway-instellingen, en bekijk daarna serverlogs voor merchant-validatie en gateway-foutcodes.
Zo test je veilig zonder echte kaarten te belasten:
Gebruik de Simulator voor snelle UI-checks, maar verifieer altijd op voor Wallet-setup, biometrie en netwerkcondities.
Voor betere conversie:
Houd Apple Pay als een eigen funnel zichtbaar. Handige signalen:
Voer A/B-tests uit op knopplaatsing en messaging en vergelijk afrondings- en annuleringspercentages van Apple Pay-gebruikers met andere betaalmethoden om de daadwerkelijke impact te meten.
Je moet ook actief zijn in regio’s en bij banken waar Apple Pay beschikbaar is en verifiëren dat je merchantcategorie en producten voldoen aan Apple’s regels.
PKPaymentRequest met merchant identifier, land, valuta, ondersteunde netwerken en summary items.PKPaymentButton waar gebruikers besluiten te betalen.PKPaymentAuthorizationController met je request.didAuthorizePayment stuur je payment.token naar je backend voor verwerking..success of .failure terug en sluit je het sheet.Het systeem UI regelt het grootste deel van de complexiteit (biometrie, tokencreatie).
PKPaymentButtonDeze patronen verminderen frictie en maken Apple Pay een snelle, betrouwbare weg naar afrekenen.