14 okt. 2025·8 min
Apple Pay i mobilappar: vad det är och hur det fungerar
Lär dig vad Apple Pay i mobilappar är, hur det fungerar bakom kulisserna och hur du integrerar det säkert för att snabba upp kassan och förbättra konvertering.
Lär dig vad Apple Pay i mobilappar är, hur det fungerar bakom kulisserna och hur du integrerar det säkert för att snabba upp kassan och förbättra konvertering.
Apple Pay är Apples digitala plånbok och betalningstjänst. Den låter användare lagra kreditkort, betalkort och vissa förbetalda och butikskort säkert på sin iPhone, Apple Watch, iPad eller Mac och betala med ett enda tryck eller en blick.
Istället för att skriva in kortnummer och faktureringsuppgifter autentiserar användaren sig med Face ID, Touch ID eller enhetslösenkod. Apple genererar en enhetsspecifik token så att det riktiga kortnumret inte delas med handlaren.
Apple Pay fungerar i tre huvudkontexter:
Denna guide fokuserar på Apple Pay i app, där hela betalningsupplevelsen stannar i appen.
Att skriva kortuppgifter på en liten skärm är långsamt och felbenäget. Apple Pay ersätter flera formulärfält med en interaktion, vilket ofta:
Eftersom kort och adresser redan är lagrade på enheten minskar Apple Pay också friktion för nya kunder.
Apple Pay fungerar på nyare iPhone, iPad, Apple Watch och Mac‑modeller i stödjande regioner, med stora nätverk som Visa, Mastercard, American Express och många lokala scheme, beroende på utfärdande bank.
Apple Pay är mest lämpligt när:
Det bör finnas sidan‑vid‑sida med traditionella kortformulär och andra wallets, inte ersätta dem helt, så att användare utan Apple Pay fortfarande kan betala.
Apple Pay döljer mycket komplexitet bakom en enkel “double‑click to pay”‑upplevelse. Under huven samordnar flera parter och säkerhetslager för att flytta pengar på ett säkert sätt.
En typisk Apple Pay‑transaktion involverar:
När en användare lägger till ett kort i Apple Wallet skickas det verkliga kortnumret (FPAN, Funding Primary Account Number) säkert till kortnätverket och utfärdaren. De svarar med en DPAN (Device Primary Account Number) plus kryptografiska nycklar unika för den enheten.
DPAN är vad Apple Pay använder under transaktioner. Din app och backend ser aldrig FPAN. Detta är kärnan i Apple Pay:s tokeniseringsmodell: enheten använder ett ersättningskortnummer och engångskryptogram istället för att exponera det riktiga kortet.
På stödjande enheter lagras betalningsuppgifter och nycklar i Secure Element (eller skyddas via Secure Enclave). När användaren autentiserar sig (Face ID, Touch ID eller lösenkod) gör Secure Element:
Din app mottar denna ogenomskinliga, krypterade token via Apple Pay‑API:erna och skickar den till din backend, som vidarebefordrar den till PSP:n eller gatewayen.
PSP:n dekrypterar tokenen, extraherar DPAN och kryptogrammet och skickar en auktoriseringsbegäran genom kortnätverket till den utfärdande banken. Utfärdaren validerar kryptogrammet och kortets status och godkänner eller avslår.
Senare, under avveckling, fångas det auktoriserade beloppet, batchas och flyttas från utfärdande bank till handlarens förvärvande bank. För din app är detta bara en fångst eller försäljningsavslutning, men bakom kulisserna koordineras det mellan förvärvare, kortnätverk och utfärdare med hjälp av DPAN — inte kundens riktiga kortnummer.
Innan du lägger till Apple Pay i din app måste du uppfylla en uppsättning tekniska, affärsmässiga och regionala krav.
På handlarens sida måste du ha:
Många handlare skapar också ett Merchant Identity‑certifikat för handlarvalidering under webbaserade eller hybridflöden.
Apple Pay i appar stöds på:
Kontrollera Apples aktuella dokumentation för minimikrav, särskilt om du förlitar dig på nyare API:er.
Apple Pay finns inte i alla länder eller för alla banker. Du måste bekräfta:
Apple kan begränsa vissa handlarkategorier och användningsområden (t.ex. olagliga varor, vissa digitala innehåll eller tjänster, högriskbranscher). Kontrollera att:
Slutligen behöver du en PSP eller betalningsgateway som stöder Apple Pay‑tokenisering och dekryptering. Bekräfta att din leverantör:
Ett smidigt Apple Pay‑flöde känns nästan osynligt för användaren. Så här ser det oftast ut steg för steg.
Resan börjar vanligtvis på en produktsida eller kundvagnsskärm. När användaren har valt varor och alternativ (storlek, färg, antal) går hen till kassan.
På kassa‑ eller kundvagnsskärmen visar du den standardiserade Apple Pay‑knappen som Apple tillhandahåller. Den bör:
När användaren trycker på knappen glider Apple Pay‑sheetet upp från botten av skärmen.
Detta sheet innehåller vanligtvis:
Användaren kan justera uppgifter (kort, frakt, kontakt) direkt i sheetet innan bekräftelse.
För att auktorisera betalningen autentiserar användaren sig med:
Sheetet uppmanar tydligt användaren, t.ex. “Double‑click to pay” på Face ID‑enheter.
Efter autentisering visar sheetet framsteg och försvinner, och användaren återvänder till din app.
Din app bör omedelbart visa ett tydligt tillstånd:
Att hålla dessa tillstånd tydliga och konsekventa försäkrar användarna om att betalstatusen är entydig och att de behåller kontroll under hela flödet.
Implementationen av Apple Pay på iOS kretsar kring PassKit‑ramverket och några nyckelklasser. Här är slut‑till‑slut‑flödet på appnivå.
Detta kopplar ditt app‑bundle till din merchant‑identitet så Apple Pay‑tokens kan genereras för din server.
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 och currencyCode måste matcha din merchant‑inställning. supportedNetworks speglar de kortscheman du och din PSP stödjer. Inkludera minst .capability3DS i merchantCapabilities.
PKPaymentButtonAnvänd PKPaymentButton istället för egna knappar så du följer Apples UI‑riktlinjer:
let payButton = PKPaymentButton(paymentButtonType: .buy, paymentButtonStyle: .black)
Placera den där köplusten är starkast: produktsidan, kundvagnen och sista checkout. Inaktivera eller dölj den om PKPaymentAuthorizationController.canMakePayments() är false.
PKPaymentAuthorizationController och hantera callbacksSkapa en controller från requesten och conforma till 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)
}
}
I didAuthorizePayment skickar du payment.token till din server för faktisk debitering. Efter att din server svarat, kalla completion med .success eller .failure, och stäng sedan sheetet i paymentAuthorizationControllerDidFinish.
Serverlogiken är vad som förvandlar ett Apple Pay‑sheet till riktig pengaförflyttning. Appen samlar användarauthorisering; din backend validerar handlaren, bearbetar tokenen och pratar med din betalningsgateway.
Innan du visar Apple Pay‑sheetet måste din app hämta en merchant‑session från Apple.
PKPaymentAuthorizationController till din backend.Detta flöde bevisar för Apple att appen är associerad med din merchant‑identitet och domän.
Efter att användaren auktoriserat får appen en krypterad betalningstoken (PKPaymentToken) och skickar den till din backend över HTTPS.
På servern:
Gatewayen dekrypterar tokenen (med nätverkstokens eller DPANs) och kör kortauktorisation med kortnätverken.
Gateways ger vanligtvis två flöden:
Din backend bör spara gatewayens transaktions‑ID, belopp, valuta och status — men inte rå kortdata eller dekrypterat tokeninnehåll.
Spara endast det du verkligen behöver för avstämning, återbetalningar och kundsupport:
Lagra aldrig fullständiga kortnummer, CVV eller okrypterade betalningstokens på dina servrar. Avlasta känslig hantering till PCI‑kompatibla gateways och se till att all kommunikation sker över TLS med strikt loggning och åtkomstkontroller.
Apple Pay är designat så att din app aldrig rör råa kortnummer, men du måste ändå förstå säkerhetsmodellen och ditt ansvar.
När en användare lägger till ett kort i Apple Pay ersätter utfärdaren och nätverket det faktiska PAN (kortnumret) med ett Device Account Number (DAN).
Under en betalning:
Din app och backend ser bara tokens och transaktionsmetadata, inte de underliggande kortuppgifterna.
Känsliga nycklar och betalningsuppgifter lagras och bearbetas i Secure Enclave, en hårdvaru‑isolerad koprocessor.
Autorisation är knuten till användarverifiering:
Din app får bara ett lyckat eller misslyckat signal från systemets sheet; den får aldrig åtkomst till biometric‑data eller Secure Enclave‑innehåll.
Varje Apple Pay‑transaktion använder:
Nätverken och utfärdarna validerar dessa värden, vilket hjälper till att upptäcka kloning, replay och manipulation.
Apple Pay kan avsevärt minska PCI DSS‑omfånget för din app eftersom:
Men:
För formell vägledning, konsultera din förvärvare, PSP och en kvalificerad säkerhetsassessor.
Apple Pay minskar risker, men slarviga integrationer kan återinföra exponering.
Praktiska tips:
Genom att respektera dessa gränser utnyttjar du Apple Pay:s inbyggda skydd samtidigt som du håller din egen efterlevnadsbörda hanterbar.
Noggrann testning är det enda sättet att vara säker på att din Apple Pay‑integration beter sig korrekt för riktiga kunder. Det börjar med rätt sandbox‑setup och en tydlig testplan.
I ditt Apple Developer / App Store Connect‑konto skapar du sandbox‑testare under Users and Access → Sandbox. Dessa speciella Apple‑ID:n används på testenheter för att simulera riktiga användare utan att debitera riktiga kort.
På dina testenheter:
Använd separata sandbox‑testare för olika användarprofiler (regioner, valutor, kortschema) så att du kan reproducera kantfall konsekvent.
iOS‑Simulatorn stöder grundläggande Apple Pay‑testning, vilket är användbart för snabb UI‑validering och tidig utveckling. Du kan simulera auktorisation och kontrollera att PKPaymentAuthorizationController‑flödet fungerar.
Men testa alltid på fysiska enheter eftersom endast de ger:
Behandla Simulator som en bekvämlighet, inte en ersättning.
Täck åtminstone följande flöden end‑to‑end (klient och server):
Använd gateway‑specifika testkortnummer och triggers för att tvinga fram avslag och felkoder.
Logga tillräckligt för att spåra problem, men logga aldrig känsliga betalningsdata. Undvik:
Logga istället:
created → authorized → captured → failed)Korrelera klientloggar med serverloggar via ett delat correlation‑ID som skickas från app till backend.
Under testcykler, håll koll på:
Om du ser intermittenta fel eller långsamma auktorisationer, kontrollera både gatewayns status och Apples status innan du antar ett integrationsfel. Det sparar tid och förhindrar att tillfälliga plattformsproblem jagas som kodbuggar.
Genomtänkt Apple Pay‑design kan göra det till en stor konverteringsdrivare. Små placeringar och textråd har stor påverkan på hur ofta användare väljer det.
Använd Apple Pay där köplusten är starkast:
Undvik att gömma Apple Pay bakom extra tryck som “Fler betalningsalternativ”. Varje extra steg minskar användandet.
Erbjud Apple Pay som en expresscheckout från:
När det används som expresscheckout, var tydlig med att frakt och kontaktuppgifter hanteras under Apple Pay‑auktorisationen.
Följ Apples Human Interface Guidelines:
Undvik egna färger eller ikoner som minskar igenkänningen eller bryter mot varumärkesregler.
Låt Apple Pay göra jobbet:
Målet är ett avgörande tryck, inte en flerstegs‑tratt.
Det snabbaste sättet att förlora en försäljning är ett förvirrande felmeddelande. Planera för fel med:
Logga fel tyst för ditt team, men visa användarna bara vad de behöver för att förstå vad som hände och vad de kan göra härnäst.
De flesta Apple Pay‑problem beror på felkonfiguration.
Det första att bekräfta är att det merchant ID som används i koden exakt matchar det som finns i Apple Developer‑kontot och i din betalgateway. Ett enda teckenfel (eller ett sandbox‑merchant ID i produktion) bryter flödet.
Verifiera även entitlements och capabilities:
Om Apple Pay‑knappar inte visas eller sheetet aldrig öppnas är konfiguration den troligaste orsaken.
Apple Pay kan vara tillgängligt i vissa länder, utfärdare eller enheter men inte i andra.
Använd PKPaymentAuthorizationController.canMakePayments() och canMakePayments(usingNetworks:) innan du visar Apple Pay‑knappen. Om de returnerar false, dölj knappen och presentera en tydlig förklaring samt ett alternativt betalningssätt.
När användare rapporterar att kort “inte stöds”, kontrollera:
Merchant‑valideringsfel syns ofta som att Apple Pay‑sheetet snabbt stängs eller aldrig visas.
För native‑appar orsakas de ofta av:
På servern, logga:
Dessa loggar pekar oftast direkt på den felkonfigurerade komponenten.
Inte alla fel är tekniska; många är utfärdaravslag.
Inspektera alltid gatewayens eller processorns svar. Särskilj mellan:
Kartlägg dessa kategorier till användarvänliga meddelanden som:
Undvik att visa råa gateway‑felkoder eller onödig teknisk information.
För att hålla Apple Pay stabilt i produktion, investera i strukturerad loggning kring varje betalningsförsök:
Sätt upp dashboards och larm för ökningar i avslag, merchant‑valideringsfel eller timeouts. Korrelera klient‑händelser med serverloggar för att snabbt spåra var fel uppstår.
Denna observabilitet minskar felsökningstiden avsevärt när problem dyker upp i live‑trafik.
När Apple Pay är live i din mobilapp behöver du bevisa att det faktiskt förbättrar kassan, inte bara ser modernt ut. Det innebär att spåra rätt händelser, övervaka nyckelmetrik och köra strukturerade experiment.
Börja med en tydlig funnel och logga händelser i varje steg:
Korrelera dessa händelser med kontext:
Detta visar var användare faller bort och om problemen är UX‑relaterade (avbokningar), tekniska (auktorisationsfel) eller backend‑relaterade (fångstfel).
Ett fokuserat metrikset gör det enklare att bedöma påverkan:
Spåra dessa över tid och över app‑versioner för att se om Apple Pay‑integration och UX‑ändringar rör siffrorna.
Kör experiment för att optimera Apple Pay:s påverkan:
Mät skillnader i adoption, framgångsfrekvens, tid till betalning och konvertering. Även små layoutförändringar kan ge tydliga vinster.
Integrera analys så att du respekterar Apple Pay:s integritetsgarantier och gällande regler:
Stora analysplattformar (t.ex. Mixpanel, Amplitude, Firebase) kan hantera dessa Apple Pay‑händelser så länge payloads är fria från känsliga betalningsuppgifter.
Insikter från Apple Pay sträcker sig bortom den knappen:
Med tiden hjälper dessa mätningar dig att förfina inte bara Apple Pay i appen utan hela checkout‑upplevelsen, så varje steg blir snabbare, tydligare och mer förtroendefullt för användarna.
Att stödja Apple Pay slutar sällan vid en enda iOS‑app. Användare förväntar sig att kunna betala på samma sätt över enheter och kanaler, och dina implementationsval bör återspegla det.
Native appar använder PKPaymentAuthorizationController och skickar betalningstokens direkt till din backend. Detta ger:
Apple Pay på webben (Safari) använder JavaScript och Payment Request API. Det är bra när du:
För många team är optimal lösning: native Apple Pay i appen och Apple Pay på webben i Safari, med en gemensam backend‑betalningspipeline.
Om du även stödjer Google Pay, PayPal eller liknande wallets, synkronisera hög‑nivåflödet:
Så känns det inte som att byta till en helt ny process när användaren byter enhet eller betalmetod.
För React Native, Flutter och liknande ramverk förlitar du dig vanligtvis på:
Testa på iPhone, iPad och Apple Watch där det är relevant:
Sikta på ett enhetligt designsystem och kassalogik som spänner över iOS, webben och andra plattformar, med tunna integrationslager för varje kanal snarare än engångsimplementationer.
Att hålla Apple Pay hälsosamt handlar mindre om stora omskrivningar och mer om disciplinerad underhåll.
Apple Pay förlitar sig på merchant‑ID:n och Payment Processing‑certifikat som löper ut.
Skapa en ägarskapskarta: vem äger Apple Developer‑kontot, var certifikat finns och hur de används i CI/CD och servrar.
Gör sedan:
Varje större iOS‑release bör trigga en testcykel för Apple Pay‑flöden på beta och finala builds. Fokusera på:
Övervaka:
Planera en designgranskning minst årligen för att anpassa ordval, knappplacering och tillgänglighet efter senaste riktlinjer.
Kortnätverk, valutor och stödregioner ändras över tid. Håll dem konfigurerbara:
Koordinera med din gateway när de lägger till nätverk eller lokala metoder, och uppdatera PKPaymentRequest därefter.
Vid gateway‑byten, appomstruktureringar eller tokenformatuppdateringar:
Dokumentera dessa flöden så nya teammedlemmar kan underhålla dem utan att behöva vända på allt.
Räkna med djupare tokenisering med nätverken, rikare kvitton och orderuppdateringar i Wallet, samt tätare kopplingar mellan in‑app, webb och butik. Funktioner som Tap to Pay on iPhone och regionala finansieringsalternativ kommer att fortsätta expandera, så designa din integration konfigurationsdriven och redo att anta nya möjligheter utan att göra om kärnflödet.
Apple Pay är Apples digitala plånbok som låter användare betala med kort som lagrats på deras iPhone, iPad, Apple Watch eller Mac.
I mobilappar ersätter det manuell kortinmatning med ett säkert system‑sheet där användare bekräftar betalningen via Face ID, Touch ID eller lösenkod. Appen får en krypterad betalningstoken istället för rå kortdata, och skickar den till din backend och betalningsgateway för att slutföra debiteringen.
Detta gör kassan snabbare, minskar fel och håller kortnummer utanför din apps infrastruktur.
Du bör lägga till Apple Pay när:
Apple Pay fungerar bäst som ett ytterligare alternativ tillsammans med kort, PayPal med flera. Ta inte bort andra betalmetoder — erbjud Apple Pay som den snabbaste vägen för användare som kan använda det.
Som ett minimum behöver du:
På iOS gör du följande i stora drag:
Enheten skapar en krypterad betalningstoken som innehåller:
Denna token är krypterad för din betalprocessor, så din app och backend behandlar den som en ogenomskinlig blob. Din backend vidarebefordrar den till gatewayen, som dekrypterar, skickar en auktoriseringsförfrågan till kortnätverket och utgivaren, och returnerar sedan godkännande eller avslag.
Du ser aldrig den faktiska PAN eller kryptografiska nycklar; du får bara transaktionsmetadata och status.
Din backend bör:
Försök inte att dekryptera token själv eller lagra dem långsiktigt. Låt din PCI‑kompatibla gateway hantera all känslig kortbearbetning.
Vanliga felkällor inkluderar:
Börja med att kontrollera konfiguration i Apple Developer‑portalen, Xcode‑entitlements och gateway‑inställningar, och granska sedan serverloggar för merchant‑validering och gateway‑felkoder.
För att testa Apple Pay säkert:
Använd Simulatorn för snabba UI‑kontroller, men validera alltid på för att testa Wallet‑setup, biometri och verkliga nätverksförhållanden.
För bättre konvertering:
PKPaymentButton med korrekt varumärke och tydlig närliggande text (t.ex. “Betala direkt med Apple Pay”).Spåra Apple Pay som en egen funnel. Bra signaler är:
Kör A/B‑test för knappplacering och budskap, och jämför Apple Pay‑användares slutförande‑ och avbokningsfrekvenser mot andra betalmetoder för att se om det verkligen förbättrar kassan.
Du måste också verka i regioner och banker där Apple Pay stöds och säkerställa att din merchant‑kategori och dina produkter följer Apples regler.
PKPaymentRequest med merchant identifier, country, currency, supported networks och summary items.PKPaymentButton där användaren beslutar att betala.PKPaymentAuthorizationController med din request.didAuthorizePayment skickar du payment.token till din backend för bearbetning..success eller .failure och stänger sheetet.Mycket av den tunga hanteringen (biometri, token‑skapande) sköts av systemets UI.
Dessa mönster minimerar friktion och gör Apple Pay till ett snabbt, pålitligt alternativ.