# Slik tar du imot kortbetalingar i ein tilpassa POS-app

> Published: 2026-10-27
> Updated: 2026-10-27
> Author: Mathias Nielsen
> Category: Pay
> Canonical: https://finalpos.com/nn/blog/slik-tar-du-imot-kortbetalingar-i-ein-tilpassa-pos-app

Eit kortskjema er ikkje ein kortterminal. Her er dei fire reelle måtane å ta imot kortbetalingar på i ein tilpassa eller KI-bygd POS-app, kva Apple, Google og betalingsleverandøren din krev for kvar av dei, og kor lang tid det tek.

For å ta imot kortbetalingar i ein tilpassa POS-app, går du gjennom ein betalingsleverandør (PSP) og ein av fire vegar: ein sertifisert kortlesar, Tap to Pay på iPhone, Tap to Pay på Android, eller ein skykopla smartterminal. Appen din les aldri eit kortnummer. Han sender eit beløp til sertifisert maskinvare eller programvare, og får tilbake godkjent eller avvist. Kvar veg har sine eigne krav frå Apple, Google eller leverandøren din, og det papirarbeidet, ikkje koden, er det som tek tid.

Denne guiden legg fram kvar veg steg for steg, med dei reelle krava og ingenting oppblåst. Vi kjører betalingar for vårt eige POS, Final, så vi har vore gjennom kvar av desse.

![Ta imot kortbetalingar i ein tilpassa POS-app: eit kontaktlaust kort tæppa på ein næringsdrivande sin telefon på ein 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)

## Kvifor kan du ikkje berre leggje til eit kortskjema i POS-systemet ditt?

Fordi eit kortskjema gjer salet til et nettsal (card-not-present), og ein butikkdisk krev fysisk betaling (card-present). Når ein kunde skriv inn eit kortnummer i eit nettskjema, blir betalinga handsama som ein nettbestilling: høgare gebyr, meir eksponering for svinn og svindel, og meir av tvisterisikoen på deg. Når ein sertifisert eining les kortet eller telefonen, er betalinga fysisk (card-present), noko som er rimelegare og tryggare for alle.

Aksept av fysiske betalingar krev sertifisert maskinvare eller programvare. Det er grunnen til at kvar veg nedanfor går gjennom in-person-produktet til ein PSP heller enn din eigen kode. Gebyrforskjellen er forklart i [fysisk betaling mot nettbetaling (card present vs card not present)](/en-US/blog/card-present-vs-card-not-present).

## Veg 1: Korleis brukar du ein kortlesar med din eigen app?

Vel ein PSP med ein in-person-SDK, kjøp ein av dei sertifiserte lesarane deira, og par han frå appen din. Stripe Terminal, Adyen og andre fungerer på denne måten.

1. Opna ein konto hos PSP-en og aktiver in-person-produktet deira.
2. Integrer iOS-, Android- eller React Native-SDK-en deira.
3. Bestill sertifiserte lesarar og registrer dei på kontoen din.
4. Oppdag og kople til lesarar frå appen din, og ta deretter imot betalingar gjennom SDK-en.
5. Planlegg for oppdateringar av lesaren sin fastvare (firmware), som PSP-en skyv ut.

Du kan ikkje kople til ein kva som helst lesar: berre lesarar sertifiserte med leverandøren din kan handsame kort, fordi sertifisering dekker den nøyaktige kombinasjonen av lesar, programvare og innløysar. Meir i [kortlesarar for tilpassa POS-appar](/en-US/blog/card-reader-sdk-custom-pos) og [EMV-sertifisering for eit POS](/en-US/blog/emv-certification-pos).

## Veg 2: Kva krev Tap to Pay på iPhone?

Tap to Pay på iPhone gjer telefonen om til lesaren. Apples eigne steg er: jobb med ein støtta PSP, be om Tap to Pay på iPhone-rettigheita (entitlement), integrer ProximityReader API-et eller din PSP sin SDK, følg Apples retningslinjer for grensesnitt (Human Interface Guidelines), og send appen inn til vurdering ([Apples Tap to Pay-oversikt](https://developer.apple.com/tap-to-pay/)). Apple oppgjev at PSP-en er ansvarleg for sertifiseringane som lèt brukarstader ta imot betalingar.

I praksis tyder det:

1. **Ein organisasjonsutviklarkonto.** Forespørselen om rettigheit må komme frå kontoeigaren (Account Holder) av ein organisasjonskonto, og registrering som organisasjon krev eit D-U-N-S-nummer. Sjå [D-U-N-S-nummer og Apple-utviklarkontoar](/en-US/blog/duns-number-apple-developer).
2. **Forespørselsskjemaet.** Namngjev PSP-en din og regionane du skal operere i.
3. **Ein utviklingsrettigheit.** Apple gjev ein for byggjing og testing på eigne einingar.
4. **Apples UX-krav.** Apple sender sine krav og retningslinjer for marknadsføring saman med rettigheita, noko som dekker knappetekstar, inngangspunkt og ombordstiging.
5. **Ein distribusjonsrettigheit.** Du svarar på Apples e-post og ber på nytt om distribusjon. TestFlight og App Store krev denne.
6. **App Review.** Appen din blir lansert når han er godkjend.

Det kjører på iPhone XS eller nyare og ikkje på iPad. Den fullstendige gjennomgangen er i [slik får du Tap to Pay på iPhone-rettigheita](/en-US/blog/tap-to-pay-iphone-entitlement), med vurderingstips i [å bestå App Review med ein Tap to Pay-app](/en-US/blog/tap-to-pay-app-review) og alternativ i [kvifor Tap to Pay ikkje fungerer på iPad](/en-US/blog/tap-to-pay-on-ipad).

## Veg 3: Korleis skil Tap to Pay på Android seg ut?

Det finst inga rettigheit i Apple-stil på Android, men PSP-en sin SDK handhevar sine eigne sjekkar. Typiske krav:

- Ein Android-eining med innebygd NFC som kjører Android 11 eller nyare
- Ein Google-sertifisert eining som består integritetstesting
- Eit ikkje-feilsøkbart bygg (non-debuggable build): PSP SDK-ar nektar å ta imot reelle tæppingar i feilsøkingsmodus, så du testar med ein simulert lesar
- Plassering og andre løyve som SDK-en be om

Android-nettbrett kan fungere dersom dei oppfyller leverandøren sine krav. Detaljar i [Tap to Pay på Android i ein tilpassa app](/en-US/blog/tap-to-pay-android-sdk).

## Veg 4: Kan eit nettlesarbasert POS ta imot kort?

Ja, gjennom ein skykopla smartterminal. Tenaren din ber PSP-en sitt API om å sende ein betaling til ein spesifikk terminal på disken; terminalen handterer kortet og rapporterer resultatet tilbake til tenaren din. Dette er den einaste in-person-vegen eit nett-POS kan bruke, fordi ei nettside ikkje kan lese eit tæppa kort og Safari ikkje kan nå Bluetooth-lesarar.

Det passar for kassebetente butikkar med ein fast terminal. Det legg til ein nettverksavhengigheit, så planlegg kva som skjer når butikken si tilkopling fall ut.

## Korleis vel du betalingsleverandør for eit tilpassa POS?

Start med landa du sel i, deretter ombordstiging og maskinvare:

| Spørsmål | Kvifor det speler ein rolle |
| --- | --- |
| Er leverandøren live i landa dine? | Tap to Pay og lesarar rullast ut land for land |
| Er ombordstiging sjølvbetent? | Stripe er sjølvbetent; Adyen fokuserer på større verksemder og vurderar søkjarar meir selektivt |
| Kva for SDK-ar tilbyr han? | iOS, Android, React Native og tenardrivne terminalar skil seg etter leverandør |
| Kva for lesarar er sertifiserte? | Berre sertifiserte lesarar fungerer |
| Støttar han frakopla betalingar? | Lagring og etterfølgjande sending (store-and-forward) er leverandørspesifikt og flyttar avvisingsrisikoen over på deg |
| Tar du om bord andre brukarstader? | I så fall er du ein plattform og kan trenge betalingsfasilitator-avtalar (payfac) |

Samanlikninga vår side om side er [Stripe Terminal vs Adyen for ein tilpassa POS-app](/en-US/blog/stripe-terminal-vs-adyen). Dersom du planlegg å ta imot betalingar på vegner av andre verksemder, les [bli betalingsfasilitator eller bruk ein plattform](/en-US/blog/payment-facilitator-vs-platform) først; for ein enkelt butikk er du berre ein brukarstad.

## Kva for samsvar arvar du, og kva behheld du?

Ved å bruke ein PSP sin sertifiserte SDK eller lesar kjem kortdata aldri i berøring med koden din, noko som held PCI-omfanget ditt lite. PSP-en ber betalingssertifiseringane. Du beheld framleis:

- Eit PCI-egenvurderingsskjema med innløysaren din
- Tilgangskontroll, meirking/logging og oppdateringar på einingane som kjører POS-systemet ditt
- Korrekte kvitteringar, refusjonar og skatte-tilbakeføring
- Apple sine og din PSP sine visnings- og marknadsføringsreglar for Tap to Pay

Dersom du byggjer resten av POS-systemet også, dekker hovudartikkelen vår om å [byggje ditt eige POS-system med KI](/en-US/blog/build-your-own-pos-system-with-ai) PCI, skatt og distribusjon, og [POS-maskinvare for tilpassa appar](/en-US/blog/pos-hardware-for-custom-apps) dekker skrivarar og skuffer.

## Kor lang tid tek det å ta imot den første kortbetalinga si?

| Steg | Typisk tid |
| --- | --- |
| Organisasjons-Apple-konto med D-U-N-S (for Tap to Pay på iPhone) | Dagar til nokre veker |
| PSP-konto og in-person-produkt aktivert | Same dag til fleire veker, avhengig av leverandør |
| SDK-integrasjon og testbetalingar | 1 til 3 veker |
| Tap to Pay-utvikling, deretter distribusjonsrettigheit | Veker |
| App Review | Dagar, lengre dersom avslått |

## Kan du ta imot kort på dag én i staden?

Ja, ved å byggje kassen din på ein plattform som allereie har godkjenningane på plass. Det er Final. KI-en din byggjer kassen i Flow Studio, og når han be om ein kortbetaling, handterer Final Pay lesaren eller Tap to Pay:

- **Lesarar og Tap to Pay allereie godkjend.** Final Pay tek imot kort, kontaktlaust og Tap to Pay på støtta einingar. Sjå [slik tek du imot ein Tap to Pay-betaling](/help/take-a-tap-to-pay-payment) og [slik tek du imot ein betaling ved kassen](/help/take-a-payment).
- **Din eigen KI byggjer det.** Kople til Claude, Cursor eller ein kva som helst MCP-klient gjennom [Final sin MCP-tenar](/help/connect-your-own-ai-mcp).
- **Prising på éi linje.** Inget abonnement. Kontant er $0. Kort er 2,49 % + $0,10 i USA og resten av verda, 1,99 % i Canada og 0,99 % i Europa.

Den ærlege avveginga: du handsamar gjennom Final Pay heller enn å velje din eigen leverandør, og tilgjenge varierer etter land og eining, oppført i [kvar Final Pay er tilgjengeleg](/help/where-final-pay-is-available). Dersom betalingar er produktet ditt, bygg integrasjonen sjølv ved å bruke vegne ovanfor. Dersom betalingar er korleis du får betalt, er godkjenningane allereie gjort.

## FAQ

**Q: Korleis tar eg imot kortbetalingar i min eigen POS-app?**
A: Gjennom SDK-en til ein betalingstenesteleverandør for fysisk betaling: ein sertifisert kortlesar, ein skykopla smartterminal eller Tap to Pay på ein telefon. Appen din handterer aldri rå kortdata; han sender eit beløp og mottek eit resultat.

**Q: Kan eit nettbasert POS ta imot kortbetalingar fysisk?**
A: Ja, ved å styre ein skykopla smartterminal gjennom betalingsleverandøren sitt API. Ei nettside kan ikkje lese eit tæppa kort åleine.

**Q: Kva krev Tap to Pay på iPhone?**
A: Ein støtta betalingsleverandør, Tap to Pay-rettigheita beom av kontoeigaren (Account Holder) for ein organisasjons Apple-utviklarkonto, ein utviklingsrettigheit og deretter ein distribusjonsrettigheit etter Apples UX-vurdering, samt App Review. Det fungerer på iPhone XS eller nyare.

**Q: Fungerer Tap to Pay på iPad?**
A: Nei. Tap to Pay på iPhone er berre for iPhone. iPad POS-appar tar imot kort med ein sertifisert Bluetooth-lesar eller ein smartterminal.

**Q: Kva for ein betalingsleverandør bør ein tilpassa POS bruke?**
A: Stripe Terminal er sjølvbetent og raskt å kome i gang med for små team. Adyen passar for større verksemder og er meir selektiv med onboarding. Land, maskinvare og volum avgjer resten.

**Q: Kva tek Final for kortbetalingar?**
A: Einkvart abonnement finst ikkje. Kontantar er $0, og kort er 2,49 % + $0,10 i USA og resten av verda, 1,99 % i Canada og 0,99 % i Europa.