# Hur du tar emot kortbetalningar i en anpassad POS-app

> Published: 2026-10-27
> Updated: 2026-10-27
> Author: Mathias Nielsen
> Category: Pay
> Canonical: https://finalpos.com/sv/blog/hur-du-tar-emot-kortbetalningar-i-en-anpassad-pos-app

Ett kortformulär är inte en kortterminal. Här är de fyra riktiga sätten att ta emot kortbetalningar i en anpassad eller AI-byggd POS-app, vad Apple, Google och din betalleverantör kräver för varje sätt och hur lång tid det tar.

För att ta emot kortbetalningar i en anpassad POS-app går du via en betaltjänstleverantör (PSP) och en av fyra vägar: en certifierad kortläsare, Tap to Pay on iPhone, Tap to Pay på Android eller en molnansluten smart terminal. Din app läser aldrig ett kortnummer. Den skickar ett belopp till certifierad hårdvara eller mjukvara och får tillbaka godkänd eller nekad. Varje väg har sina egna krav från Apple, Google eller din leverantör, och det pappersarbetet – inte koden – är det som tar tid.

Den här guiden lägger fram varje väg steg för steg, med de verkliga kraven och inget uppblåst. Vi hanterar betalningar för vårt eget POS, Final, så vi har gått igenom allt detta själva.

![Ta emot kortbetalningar i en anpassad POS-app: ett kontaktlöst kort blippas mot en handlares telefon vid en kafédisk](https://storage.googleapis.com/final-os-media/media/43399b6a-0d29-48b6-84dd-88ef01fcb193/generated/aa1be6a479fcf8f3-accept-card-payments-custom-pos-app-hero.png)

## Varför kan du inte bara lägga till ett kortformulär i ditt POS?

Eftersom ett kortformulär gör försäljningen till en transaktion där kortet inte är närvarande (card-not-present), medan en butikskassa kräver att kortet är närvarande (card-present). När en kund skriver in ett kortnummer i ett webbformulär behandlas betalningen som en onlinebeställning: högre avgifter, större risk för bedrägerier och mer av tvistrisken hamnar på dig. När en certifierad enhet läser av kortet eller telefonen är kortet närvarande, vilket är billigare och säkrare för alla.

Betalning med kort närvarande kräver certifierad hårdvara eller mjukvara. Det är därför varje väg nedan går via en PSP-leverantörs produkt för fysisk handel snarare än din egen kod. Avgiftsdifferensen förklaras i [kort närvarande jämfört med kort ej närvarande](/en-US/blog/card-present-vs-card-not-present).

## Väg 1: Hur använder du en kortläsare med din egen app?

Välj en PSP med ett SDK för fysisk handel, köp en av dess certifierade läsare och parkoppla den från din app. Stripe Terminal, Adyen och andra fungerar på detta sätt.

1. Öppna ett konto hos PSP-leverantören och aktivera deras produkt för fysisk handel.
2. Integrera deras iOS-, Android- eller React Native-SDK.
3. Beställ certifierade läsare och registrera dem på ditt konto.
4. Upptäck och anslut läsare från din app och ta därefter emot betalningar via SDK:n.
5. Planera för uppdateringar av läsarens fasta programvara (firmware), som PSP-leverantören skickar ut.

Du kan inte ansluta vilken läsare som helst: endast läsare som certifierats med din leverantör kan behandla kort, eftersom certifieringen täcker den exakta kombinationen av läsare, mjukvara och inlösare. Mer i [kortläsare för anpassade POS-appar](/en-US/blog/card-reader-sdk-custom-pos) och [EMV-certifiering för ett POS](/en-US/blog/emv-certification-pos).

## Väg 2: Vad kräver Tap to Pay on iPhone?

Tap to Pay on iPhone gör telefonen till kortläsaren. Apples egna steg är: arbeta med en PSP som stöds, ansök om behörigheten för Tap to Pay on iPhone, integrera ProximityReader API eller din PSP:s SDK, följ Apples Human Interface Guidelines och skicka in din app för granskning ([Apples översikt för Tap to Pay](https://developer.apple.com/tap-to-pay/)). Apple anger att PSP-leverantören ansvarar för de certifieringar som gör att handlare kan ta emot betalningar.

I praktiken innebär det:

1. **Ett utvecklarkonto för organisationer.** Ansökan om behörighet måste komma från kontoinnehavaren (Account Holder) för ett organisationskonto, och att registrera sig som organisation kräver ett D-U-N-S-nummer. Se [D-U-N-S-nummer och Apple-utvecklarkonton](/en-US/blog/duns-number-apple-developer).
2. **Ansökningsformuläret.** Ange din PSP och i vilka regioner du ska verka.
3. **En utvecklingsbehörighet.** Apple beviljar en sådan för att bygga och testa på dina egna enheter.
4. **Apples UX-krav.** Apple skickar sina krav och marknadsföringsriktlinjer tillsammans med behörigheten, vilka täcker knappetiketter, ingångspunkter och onboarding.
5. **En distributionsbehörighet.** Du svarar på Apples e-postmeddelande och ansöker igen för distribution. TestFlight och App Store behöver denna.
6. **App Review.** Din app lanseras när den har godkänts.

Det körs på iPhone XS eller senare och inte på iPad. Den fullständiga genomgången finns i [hur du får behörigheten för Tap to Pay on iPhone](/en-US/blog/tap-to-pay-iphone-entitlement), med granskningstips i [att klara App Review med en Tap to Pay-app](/en-US/blog/tap-to-pay-app-review) och alternativ i [varför Tap to Pay inte fungerar på iPad](/en-US/blog/tap-to-pay-on-ipad).

## Väg 3: Hur skiljer sig Tap to Pay på Android?

Det finns ingen Apple-liknande behörighet på Android, men PSP-leverantörens SDK verkställer sina egna kontroller. Typiska krav:

- En Android-enhet med inbyggt NFC som kör Android 11 eller senare
- En Google-certifierad enhet som klarar integritetsverifiering
- Ett icke-felsökningsbart bygge (non-debuggable build): PSP SDK:er vägrar att ta emot riktiga blippar i felsökningsläge, så du testar med en simulerad läsare
- Platsbehörighet och andra behörigheter som SDK:n begär

Android-surfplattor kan fungera om de uppfyller leverantörens krav. Detaljer i [Tap to Pay på Android i en anpassad app](/en-US/blog/tap-to-pay-android-sdk).

## Väg 4: Kan ett webbaserat POS ta emot kort?

Ja, via en molnansluten smart terminal. Din server anger för PSP-leverantörens API att skicka en betalning till en specifik terminal i kassan; terminalen hanterar kortet och rapporterar resultatet tillbaka till din server. Detta är den enda vägen för fysisk handel som ett webbaserat POS kan använda, eftersom en webbsida inte kan läsa ett blippat kort och Safari inte kan nå Bluetooth-läsare.

Det passar butiker med en fast terminal vid kassan. Det skapar ett nätverksberoende, så planera för vad som händer när butikens anslutning går ner.

## Hur väljer du en betalleverantör för ett anpassat POS?

Börja med länderna du säljer i, därefter onboarding och hårdvara:

| Fråga | Varför det spelar roll |
| --- | --- |
| Är leverantören tillgänglig i dina länder? | Tap to Pay och läsare rullas ut land för land |
| Erbjuds självbetjäning vid onboarding? | Stripe har självbetjäning; Adyen fokuserar på större företag och granskar sökande mer selektivt |
| Vilka SDK:er erbjuds? | iOS, Android, React Native och serverstyrda terminaler skiljer sig åt per leverantör |
| Vilka läsare är certifierade? | Endast certifierade läsare fungerar |
| Stöds offlinebetalningar? | Lagring och vidarebefordran (store-and-forward) är leverantörsspecifikt och flyttar risken för nekade betalningar till dig |
| Tar du emot andra handlares betalningar? | Om så är fallet är du en plattform och kan behöva payfac-arrangemang |

Vår jämförelse sida vid sida är [Stripe Terminal jämfört med Adyen för en anpassad POS-app](/en-US/blog/stripe-terminal-vs-adyen). Om du planerar att ta emot betalningar för andra företags räkning, läs [bli en betalningsfacilitatör eller använd en plattform](/en-US/blog/payment-facilitator-vs-platform) först; för en enskild butik är du helt enkelt en handlare.

## Vilken efterlevnad ärver du och vad behåller du?

När du använder en PSP-leverantörs certifierade SDK eller läsare innebär det att kortdata aldrig vidrör din kod, vilket håller din PCI-omfattning liten. PSP-leverantören bär betalningscertifieringarna. Du ansvarar fortfarande för:

- Ett PCI-egenbedömningsformulär hos din inlösare
- Åtkomstkontroll, loggning och uppdateringar på enheterna som kör ditt POS
- Korrekta kvitton, återbetalningar och moms-återföring
- Apples och din PSP-leverantörs skärm- och marknadsföringsregler för Tap to Pay

Om du bygger resten av POS-systemet också täcker vår huvudartikel om hur du [bygger ditt eget POS-system med AI](/en-US/blog/build-your-own-pos-system-with-ai) PCI, moms och distribution, och [POS-hårdvara för anpassade appar](/en-US/blog/pos-hardware-for-custom-apps) täcker skrivare och kassalådor.

## Hur lång tid tar det att ta emot din första kortbetalning?

| Steg | Typisk tid |
| --- | --- |
| Organisationens Apple-konto med D-U-N-S (för Tap to Pay on iPhone) | Några dagar till ett par veckor |
| PSP-konto och produkt för fysisk handel aktiverat | Samma dag till flera veckor, beroende på leverantör |
| SDK-integrering och testbetalningar | 1–3 veckor |
| Utvecklings- och därefter distributionsbehörighet för Tap to Pay | Veckor |
| App Review | Dagar, längre vid avslag |

## Kan du ta emot kort från dag ett istället?

Ja, genom att bygga kassan på en plattform som redan har godkännandena på plats. Det är Final. Din AI bygger kassan i Flow Studio, och när den begär en kortbetalning hanterar Final Pay läsaren eller Tap to Pay:

- **Läsare och Tap to Pay redan godkända.** Final Pay tar emot kort, kontaktlösa betalningar och Tap to Pay på enheter som stöds. Se [hur du tar emot en Tap to Pay-betalning](/help/take-a-tap-to-pay-payment) och [hur du tar emot en betalning i kassan](/help/take-a-payment).
- **Din egen AI bygger det.** Anslut Claude, Cursor eller valfri MCP-klient via [Finals MCP-server](/help/connect-your-own-ai-mcp).
- **Prissättning på en rad.** Inget abonnemang. Kontant är 0 $. Kort är 2,49 % + 0,10 $ i USA och i övriga världen, 1,99 % i Kanada och 0,99 % i Europa.

Den ärliga kompromissen: du hanterar betalningar via Final Pay istället för att välja din egen leverantör, och tillgängligheten varierar beroende på land och enhet, listade i [var Final Pay är tillgängligt](/help/where-final-pay-is-available). Om betalningar är din produkt, bygg integrationen själv med hjälp av vägarna ovan. Om betalningar är hur du får betalt, är godkännandena redan klara.

## FAQ

**Q: Hur tar jag emot kortbetalningar i min egen POS-app?**
A: Via en betaltjänstleverantörs SDK för fysiska betalningar: en certifierad kortläsare, en molnansluten smart terminal eller Tap to Pay på en telefon. Din app hanterar aldrig råa kortdata; den skickar ett belopp och tar emot ett resultat.

**Q: Kan ett webbaserat POS ta emot kortbetalningar på plats?**
A: Ja, genom att styra en molnansluten smart terminal via betalleverantörens API. En webbsida kan inte läsa ett blippat kort på egen hand.

**Q: Vad kräver Tap to Pay on iPhone?**
A: En betalleverantör som stöds, Tap to Pay-behörigheten begärd av kontoinnehavaren (Account Holder) för ett Apple-utvecklarkonto för organisationer, en utvecklingsbehörighet och därefter en distributionsbehörighet efter Apples UX-granskning samt App Review. Det fungerar på iPhone XS eller senare.

**Q: Fungerar Tap to Pay på iPad?**
A: Nej. Tap to Pay on iPhone är endast för iPhone. iPad POS-appar tar emot kort med en certifierad Bluetooth-läsare eller en smart terminal.

**Q: Vilken betalleverantör ska ett anpassat POS använda?**
A: Stripe Terminal har självbetjäning och är snabbt att komma igång med för små team. Adyen passar större företag och är mer selektiva med sin onboarding. Dina länder, din hårdvara och din volym avgör resten.

**Q: Vad tar Final för kortbetalningar?**
A: Ingen prenumeration. Kontanter är $0, och kort är 2,49 % + $0,10 i USA och resten av världen, 1,99 % i Kanada och 0,99 % i Europa.