Apple stelt NFC-module ook open voor derden in landen buiten de EU

Apple gaat de NFC-chip op iPhones ook in landen buiten de EU openstellen voor externe betaalproviders. Vanaf iOS 18.1 kunnen ontwikkelaars contactloze transacties met NFC aanbieden via het Secure Element.

Ontwikkelaars kunnen met de nieuwe api's voor NFC en het Secure Element in-app contactloze transacties aanbieden. Daarmee kan in winkels betaald worden, maar de toepassingen omvatten bijvoorbeeld ook autosleutels, hotelsleutels en bedrijfspassen, aldus Apple in een aankondiging. Ontwikkelaars moeten daarvoor wel een commerciële overeenkomst met Apple sluiten, toegang tot NFC en het Secure Element aanvragen en de bijbehorende kosten betalen.

De toegang tot de NFC-module wordt gefaseerd uitgerold. In eerste instantie komen de nieuwe api's alleen in Australië, Brazilië, Canada, Japan, Nieuw-Zeeland, Groot-Brittannië en de Verenigde Staten beschikbaar, later volgen meer landen. Het is nog niet bekend wanneer de uitrol precies start. Apple zegt alleen dat dit vanaf iOS 18.1 is, maar daarvan is nog geen verschijningsdatum bekend.

De aankondiging volgt nadat Apple onder druk van de Europese Unie de NFC-module binnen de EU moest openstellen. Het bedrijf kondigde in juli aan dat het daar een overeenkomst over heeft gesloten met de Europese Commissie, die dat afdwong. Apple mag in de EU geen geld vragen voor die toegang.

Reacties (81)

[[BoSS]]

Betalen om toegang te krijgen tot hardware waar de klant ook al betaald voor heeft...?

Hoe doet Google dit met Android, is toegang tot de NFC module daar ook restricted en alleen mogelijk voor partijen met een speciale overeenkomst of voor elke willekeurige ontwikkelaar?

[djiwie]

Nee, gewoon toegankelijk voor iedere ontwikkelaar. Zijn ook talloze apps die bijvoorbeeld met NFC de gegevens kunnen laten zien die in je paspoort staan of op je creditcard.

[Seal64]

Hoe werkt dat met DigiD op de iPhone? Ik kan me herinneren dat ik in de app mijn ID kaart heb moeten scannen om aan te tonen dat ik ben wie ik ben, maar als je op een iPhone geen NFC mag gebruiken kan dat niet. Heeft die app daar een uitzondering op omdat het de overheid is dan of zo?

[Luminair]

Dat gaat om het lezen van een NFC chip, die API was al een tijdje open beschikbaar. Wat er nu bij gaat komen is dat de NFC chip als host kan dienen. Daarmee kunnen keys in de Secure Enclave worden opgeslagen om te worden om dan weer andere dingen te kunnen signeren. Komt er op neer dat je telefoon zelf dan kan dienen als een OV-Chipkaart, en dergelijke. In theorie zou de DigiD app dan ook als een ID bewijs kunnen dienen -- dat gebeurt al in beperkte staten en landen.

[Bliksem B]

Dat gaat om het lezen van een NFC chip, die API was al een tijdje open beschikbaar. Wat er nu bij gaat komen is dat de NFC chip als host kan dienen. Daarmee kunnen keys in de Secure Enclave worden opgeslagen om te worden om dan weer andere dingen te kunnen signeren. Komt er op neer dat je telefoon zelf dan kan dienen als een OV-Chipkaart, en dergelijke. In theorie zou de DigiD app dan ook als een ID bewijs kunnen dienen -- dat gebeurt al in beperkte staten en landen.

Bij het openen van deuren moest een slim gebruik maken van Apple’s Home Key (Apple Home Key voor huissleutel in de Wallet-app: zo werkt het).
Bij het openen van een deur is het slot de lezer is, waarbij iPhone fungeert als chip. Dit kon tot op heden alleen via Apple's Home Key. Een digitale sleutel die je kan koppelen aan je slimme slot. Zoals bij de Schlage Encode Plus smart lock review: unlocking your door is now as easy as using Apple Pay - The Verge.

[Reactie gewijzigd door Bliksem B op 15 augustus 2024 12:27]

[nils7]

Het artikel gaat over betaal transacties.
ID kaart scannen is geen betaaltransactie.
Ook kun je allang deuren openen met de NFC reader van de iPhone.

[rvt1]

Speculatie: ik kan mij goed voorstellen dat Apple wil gaan bijhouden wie er toegang heeft tot deze service zodat als er misbruik van wordt gemaakt dat je per aanvrager je deze kunt afsluiten van het systeem.
Je hebt dan en overeenkomst nodig dat een partij A en B mag doen, maar niet C. Dat kost natuurlijk geld…
Zie het een beetje als dat een website ook certificaten heeft, en jij ook… deze worden wel en niet vertrouwd door jouw browser, ook dat kost geld … jij merkt er wellicht niets van, maar ook daar liggen afspraken.
Het is wel jouw hardware, maar de systemen die er achter zitten weer niet..

[RobertMe]

Zie het een beetje als dat een website ook certificaten heeft, en jij ook… deze worden wel en niet vertrouwd door jouw browser, ook dat kost geld … jij merkt er wellicht niets van, maar ook daar liggen afspraken.

Lets Encrypt is gewoon gratis en prima vertrouwd overal. Dat het geld kost klopt uiteraard, maar dat betekent niet dat je die kosten direct moet verhalen.
En, pure speculatie, Apple gaat vast niet zeg ~50 euro doorrekenen omdat 1 medewerker dan 1 tot 2 uur mee bezig is. Dit gaat vast veel duurdee zijn. En de kosten zouden ze natuurlijk ook in andere zaken kunnen verwerken. Om apps voor de app store te maken moet je al betalen (voor de developer licentie, nog los van dat je een Mac moet hebben), waarom kan die dan niet zeg €1 duurder zijn zodat iedereen toegang tot NFC kan krijgen (en diegene die het niet gebruiken mee betalen). Of zeker €0,01 door aan de gebruiker en maak de telefoon duurder.

En ook daarbij, bij Android is alles gratis. Toegang tot de Play Store, om apps te publiceren, kost niks. Terwijl ook Google een controle proces heeft om malafide apps etc te weren. En zelfs Android zelf is gratis. Alleen als een fabrikant een toestel wilt leveren met Play Services (Play Store, Maps (incl location services etc), Google app uberhaupt, Assistant, ...) moet daarvoor betaald worden (en nouja, dat zit "hier" wel op alle telefoons).

En last but not least. Apple kan het dus wel "gratis" doen in Europa, maar niet in de rest van de wereld. Als de kosten écht zo hoog waren hiervoor voor Apple dan had de EU vast wel toegestaan dat deze werden doorgerekend.

[CH4OS]

Toch kun je niet overal Let's Encrypt en anderen die gratis TLS certificaten aanbieden gebruiken. Er zijn genoeg partijen die bijvoorbeeld Organization Validation (OV) of Extended Validation (EV) willen. Dat zijn certificaten die Let's Encrypt bijvoorbeeld niet uitgeeft.

Dat voor een TLS verbinding een Domain Validated (DV) certificaat voldoende is voor een browser, betekend niet direct dat het maar overal gebruikt kan worden. Bij de overheid wil je ook wel zeker weten dat je echt met (een website van) die overheid te maken hebt.

Daarmee voorkom je gedeeltelijk dat dingflofbips.phishers.tld kan zeggen dat ze bijvoorbeeld NL overheid zijn terwijl ze dat niet zijn. Natuurlijk bieden ze dan een domain validated TLS certificaat aan dat enkel valide is voor het (sub)domein zelf. Maar zo kan je ook zien dat je niet met de overheid te maken hebt (omdat de organisatie achter het domein niet gecontroleerd is).

[Reactie gewijzigd door CH4OS op 15 augustus 2024 13:33]

[RobertMe]

Oh nee, tuurlijk, maar vaak is het wel voldoende. Net zoals dat Apple niet voor elke toepassing van NFC geld zou hoeven vragen. Waarom zou je bv extra moeten betalen als je een app wilt maken om gewoon een standaard NFC pasje uit te lezen zonder daarvoor de iOS APIs te gebruiken?

En de door @rvt1 aangehaalde post van @JBVisual gaat daar IMO ook mank in. "Apple wilt geld om fatsoenlijke controles te doen zodat onveilig gebruik niet op Apple afstraalt". Ten eerste is dit schijnbaar geen probleem voor Google? Risico's zijn daar immers al jaren hetzelfde. Toch heb ik nog nooit gelezen dat Android onveilig is op basis van een app met een brakke NFC implementatie. En ten tweede, als "Apple dit om hun reputatie te beschermen", dan kunnen we dus ook 100% naar Apple wijzen als er alsnog een "gekeurde" onveilige implementatie rond gaat. Immers is de claim blijkbaar nu al "Apple keurt het zodat ze weten dat het goed is", dus als het niet goed is dan komt dat mede door Apple. De kans op reputatieschade lijkt mij dan juist groter. Immers kun je zonder specifieke keuring nog zeggen "dat het niet gekeurd is", met specifieke keuring kun je dat argument echter niet maken.
Nog los van dat AFAIK Apple helemaal geen broncode valideert. Ze testen alleen de app en of die (crashvrij) werkt. Nu zullen ze bij NFC wellicht ook de werking van NFC testen (moet je als fabrikant van een auto die je met NFC via de telefoon kunt ontgrendelen dan ook een auto opsturen? ). Maar dat geeft zonder validatie van daadwerkelijk de broncode geen enkele garantie dat de implementatie etc veilig is. Sure, een replay attack zou je kunnen testen, maar heel veel andere zaken zul je lastiger kunnen testen, terwijl je het wel in de code kunt valideren. Of beter gezegd: het design van het protocol kun je makkelijker aflezen uit code dan uit "niks". En het design van het protocol is wat bepaalt hoe veilig het is.

[Reactie gewijzigd door RobertMe op 15 augustus 2024 13:42]

[JBVisual]

Kleine off-topic aanvulling.

Apple geeft ontzettend veel om de veilige en vertrouwde waarde van hun producten. Het gaat ook om een gevoel wat ze afstralen met een bepaald beleid.

Apple gaat zelfs zo ver dat slechteriken in films/series etc.. geen Apple producten mogen gebruiken. (Bron: https://thetab.com/uk/202...C%20iPods%20or%20Macbooks)

[rvt1]

Ik denk dat JBVisual een stuk beter mijn gedachte verwoord heeft, lees dat even na..

Over Lets Encrypt, Let’s Encrypt heeft volgens mij geen extended validation. let’s Encrypt is dus prima voor een klein bedrijf, hobby etc… maar voor een bank die Lets Encrypt gebruikt zou ik die bank zeker niet vertrouwen. Er zit dus wel degelijk verschil tussen LE en andere providers. Dat extra “vertrouwen” kost nu eenmaal geld, of je het er mee eens bent of niet…

[gaskabouter]

Ik kan mij dan weer goed voorstellen dat Apple d iphone als de melkkoe gebruikt zoals het dat zal jaren doet

[ApexAlpha]

Daar is het gewoon toegankelijk, altijd geweest ook.

En het feit dat Google Pay bestaat naast de open NFC toont ook meteen aan dat Apple ongelijk heeft kwa beveiliging enzo.

[supersnathan94]

Er is geen enkele bank in Nederland meer die zijn eigen NFC implementatie heeft. Loopt allemaal via Google Pay tegenwoordig.

Eigen implementatie was duur in onderhoud en beveiliging, kostte moeite voor de klant bij het betalen en werd gewoon weinig gebruikt (was ook vaak €0,50/maand dus dat hielp ook niet mee).

Apple heeft wel degelijk gelijk dat het gewoon niet zo handig is en ik verwacht dan ook dat er geen enkele betaalinstelling hier gebruik van gaat maken.

Misschien een betalingsprovider die zijn eigen softPOS app gaat maken, maar die zal daar ws al snel mee op houden omdat het gewoon te veel kost t.o.v. Apples TapToPay.

[GertMenkel]

De app van de ING doet het nog steeds. Gaat niet lang meer duren voor die stopt, maar ik blijf hangen zolang ik kan.

Banken uit andere landen bieden nog wel gewoon eigen apps aan, al zijn dat er niet meer zo veel als het ooit geweest is.

[supersnathan94]

Bij veel mensen werkt de ING app al niet meer op die manier. Gaat gefaseerd met een einddatum van 17 september dacht ik.

De rest doet het misschien nog wel, maar heel veel zin hebben die er ook niet meer in.

[ApexAlpha]

Als Google Pay de strijdt wint door gewoon een beter product aan te bieden dan is daar helemaal niks mis mee.

Als Google Pay zou winnen omdat Google de NFC chip afsluit voor iedereen behalve zichzelf dan is dat wel een probleem.

[supersnathan94]

Google heeft al aangetoond dat het een beter alternatief bied (en daarbij Apple ook want dat werkt op eenzelfde manier) dus deze regelgeving maakt het absoluut direct obsoleet.

Prima dag ze het doen. Moeten ze vooral zelf weten, maar dat het voor banken en betaalinstellingen makkelijker en veiliger is dan zelf iets doen, is al bewezen door de concurrent.

Het open zetten gaat daarom niet zoveel toevoegen denk ik zelf.

[2TheMaks]

Als Google Pay zou winnen omdat Google de NFC chip afsluit voor iedereen behalve zichzelf dan is dat wel een probleem.

Inderdaad. Het moet voor de app van mijn auto nog wel mogelijk zijn om de telefoon middels NFC te gebruiken om de autodeuren te ontgrendelen.

[PrimusIP]

In geval van Apple pay wordt er aan de "server kant" bij Apple ook nog wat gedaan. Ik weet niet of daar nog een rol zit als je op andere manieren van die NFC chip gebruik wil maken. En dan speelt Apple nog poortwachter voor toegang tot die NFC chip, want er zitten ook risico's voor misbruik en oplichting.
Ik zeg niet niet dat ik het met Apple eens ben, wat ik wel probeer te zeggen is dat er meer is dan alleen de hardware die in de telefoon zit.

Overigens ben ik geen voorstander dat Apple er geld voor moet hebben, zeker als het buiten Apple pay om gaat. Ik ben ook voorstander dat NFC open staat voor anderen. Zelf heb ik als klant veel liever dat banken (zoals nu) gebruik maken van van Apple Pay. Maar NFC heeft zoveel meer toepassingen dan betalen.

[Blokker_1999]

Als je zelf betalingen wenst te doen via NFC in je app dan moet je ook alles zelf regelen. Apple zit daar niet meer tussen. Dit is dus enkel weg gelegd voor erkende betalingsproviders.

Ik zie ook niet direct in hoe het wegnemen van Apple ineens de kans op oplichting zou verhogen.

Zelf heb ik liever niet dat Alle er tussen zit. Zij voegen niets toe, behalve een extra stap die geld kost.

[Reactie gewijzigd door Blokker_1999 op 15 augustus 2024 12:59]

[JBVisual]

Let op dat het hier puur gaat om het aanbieden van kaarten buiten het Apple Pay systeem om;

Over de aanpassing
Het gaat erom dat je moet betalen voor een beveiligde infrastructuur van Apple. Apple wilt niet dat elk hotel straks elke app maker even makkelijk een pas toevoegt aan de iPhone die niet aan de veiligheidsvoorschriften voldoet.

Als straks de deuren van een auto, hotelkamer, vakantiehuisje geopend worden met een iPhone app die niet veilig genoeg is dan wordt Apple er door de eindgebruiker vaak toch op aangekeken.

De commerciële licentie die Apple vereist valt trouwens ook nog best mee. Deze is voor kleinere ontwikkelaars $350 (waar een standaard ontwikkelaars account $100 kost)
Voor deze $250 extra moet Apple aanvullende werkzaamheden doen om de app te controlleren, krijg je als ontwikkelaar ook tools om zelf te draaien. (Denk aan api’s die te koppelen zijn met je CRM systeem in bijvoorbeeld een hotel, om zo de digitale kamer sleutel aan te kunnen bieden maar ook het verzoek van de sleutel te laten accidenten door je “deur toegangs systeem”)

Mocht je een bank zijn, dan zijn er nog aanvullende eisen en betalingen nodig. Maar op de ontwikkeling van een app die al veilig zou moeten zijn, is dat uiteindelijk ook gewoon centenwerk voor een Bank.

Persoonlijke mening
Al met al denk ik dat Apple dit soort stappen neemt omdat ze de druk vanuit de gehele wereld beginnen te voelen, daar waar de EU momenteel het voortouw neemt.
De strijd tussen de EU en Apple is op genoeg punten nog niet uitgevochten, maar ik hoop dat de EU hun poot stijf kan houden. Uiteindelijk wilt een bedrijf als Apple niet te lang wachten omdat ze dan hun marktaandeel hier zullen gaan verliezen.
Over een paar jaar is een telefoon zonder AI ondersteuning voor de meeste mensen wat vandaag de dag een Nokia N95 zou zijn. (Leuke functies, je kan er wat mee, maar het is niet meer van deze tijd)
Dus mijn vermoeden zal zijn dat het geblaf van Apple over AI weg laten in de EU gewoon blufpoker is die van korte duur zal zijn.

[itavero]

Ik denk dat er vanuit Apple ook getest gaat worden dat deze functionaliteiten niet conflicteren met features waarbij iOS zelf de NFC chip gebruikt.
Betalen klinkt dan misschien wat flauw, maar het kan ook zo maar een middel zijn om de drempel hoger te leggen zodat ze de test effort aan hun kant kunnen beheersen.

Daarnaast snijden ze hier natuurlijk ook mee in hun eigen omzet: voor betalingen die via de externe partij gaan krijgen ze immers geen commissie meer.
Dat willen ze ongetwijfeld ook compenseren.

[PhilipsFan]

De ontwikkelaar betaalt niet om toegang te verkrijgen, hij betaalt feitelijk om aan te tonen dat hij die toegang aankan, qua verantwoordelijkheden.

Wat we nu dus gaan krijgen, is dat elke fabrikant die de NFC wil gebruiken, dit vanuit z'n eigen app gaat doen. Dus waar we nu nog voor alles de Apple Wallet kunnen gebruiken, met alle gemak vandien (niet eerst toestel ontgrendelen etc) moet je straks voor ALLES NFC een extra app installeren. Als je de NFC-functie nodig hebt, dan moet je dus eerst je toestel ontgrendelen, naar de app gaan en daar de gewenste functie gebruiken. Een gewone autosleutel gebruiken is 100x makkelijker en sneller.

Wederom: dankjewel EU. Door je (weliswaar goedbedoelde) bemoeizucht heb je het leven van Apple gebruikers weer een stukje minder makkelij gemaakt.

En dan hebben we het nog niet over kwaadwillenden, want het is er natuurlijk op wachten dat hier fraude mee gepleegd gaat worden. Betaalautomaat-app maken, langs de tassen op een festival en cashen maar.

[supersnathan94]

Ik denk dat het meevalt gelukkig. Op android bewegen banken ook allemaal naar Google Pay ten faveure van eigen implementaties. Zie ze dan op iOS niet ineens het omgekeerde doen.

[PhilipsFan]

Banken misschien niet, maar autofabrikanten? Het is aantrekkelijk om klanten naar je eigen app te drukken, want dan kun je ze weer vanalles voorschotelen en informatie over ze verzamelen.

Kijk naar Home Automation. Er zijn talloze fabrikanten van vaatwassers, wasmachines, koelkasten, airco's etc die hun eigen app aanbieden. De communicatie is versleuteld en niet toegankelijk voor andere apps. Je eindigt straks met een hele trits aan inferieure apps, terwijl er gewoon iets bestaat waar alles goed mee werkt (bijvoorbeeld Home Assistant).

[supersnathan94]

Autofabrikanten ook.

Apple heeft al een implementatie die gewoon veilig en soepel werkt. Ik ben nog geen autofabrikant tegengekomen die überhaupt een goede app kan maken om over veilige sleutels nog maar te zwijgen (BMW, Kia, ford, boeit allemaal niks).

Dus als er iets is waar je hard van weg moet lopen is het autofabrikanten die met een eigen (dure) implementatie komen van digital keys.

[2TheMaks]

Betaalautomaat-app maken, langs de tassen op een festival en cashen maar.

Vandaar dat op Android de telefoon ontgrendeld moet zijn voordat er een NFC-betaling gedaan kan worden. Juist om dit te voorkomen. Apple maakt dus niet alleen voor de eigen gebruikers het leven een stukje makkelijker.......

[jibjqrkl]

Bang dat ie ook verplicht openmoet in andere landen en er nu vast geld voor vragen voordat het gratis moet?

[AceAceAce]

De andere landen kunnen misschien niet zo'n vuist maken als de EU dat kan, dus of het in die landen ook gratis moet is maar de vraag.

En als je nu die opties hebt geimplementeerd (met kosten) voor de EU, wat let je dan als commercieel bedrijf daar geld voor te vragen? Voor Apple Pay transacties romen ze (in de VS vziw) ook een klein percentage per transactie af.

[m_snel]

Ik zie deze vuist meer een beetje als een slap handje zoals met de Windows N versie.
Maar wie weet krijgen we dan na vele decennia toch de mogelijkheid om met een device alle chip pasjes te vervangen.

[SgtElPotato]

Ben benieuwd. Hopelijk blijft mijn bank gewoon met Apple Pay werken en krijgen we geen halfbakken oplossing die niet altijd werkt.

[supersnathan94]

Ik denk dat er weinig banken zelf aan de gang gaan. Op android zijn ze daar namelijk ook van afgestapt

[Chrisjuh_15]

Laten we hopen dat dat zo blijft! Niks zo irritant als een halfbakken oplossing van een IT afdeling die denkt dat ze het beter dan Apple kunnen.

[kwaakvaak_v2]

Denk dat eerder andere toepassingen logischer zijn, loyalty cards, digitale personeelspas etc, maar vooral de auto industrie zit hier hard op te duwen volgens mij. Keyless entry met enkel je telefoon (en hopelijk wel met een extra laag als face id ertussen)

[SgtElPotato]

Daar hebben we Apple CarKey voor. En voor voordeuren hebben we HomeKey. Dat heeft wat mij betreft wel de voorkeur dan de zelfgemaakte oplossingen van fabrikanten.

[Ivo2012]

Hier in Brazilië maakt mijn bank er al gebruik van. Bij Nubank kan je kaartbetalingen accepteren via "Tap to Pay" op je iPhone.

https://nubank.com.br/taptopayiphone/

[NotSoSteady]

Volgens mij is het de bedoeling dat derden nu hun eigen dienst kunnen aanbieden met de NFC-module. Tap to Pay is nog steeds een functie van Apple.

[PrimusIP]

Werkt ook in de Londense metro, en dat is iig zeker Apple pay.

[La1974]

Heeft hier ook niets mee te maken. Dat is gewoon een reguliere transactie. Eventueel via Express mode waardoor Face/TouchId niet nodig is.

[supersnathan94]

Werkt ook bij Nederlandse OV bedrijven hoor. Nu je met betaalkaarten kunt inchecken is dat automatisch ook mogelijk met ApplePay.

Als ze hier nou ook eens een keer Express OV zouden toevoegen zou helemaal makkelijk zijn.

[PrimusIP]

Grote nadeel van het huidige NL systeem is dat je je abonnement nog niet kunt koppelen aan je bankpas. Als dat mogelijk zou zijn, zou dat ideaal zijn. Ik vind sowieso dat Nederlands OV een slechte implementatie heeft gedaan.

Met express sta ik wat dubbel in. Het is sneller maar ook weer minder veilig. Als je niks met een iPhone kan maakt het 't ook minder interessant om hem te stelen. Nu zal een OV ritje wellicht daar niet zoveel invloed op hebben, maar toch...

[supersnathan94]

Nouja. Als ze nou iig de mogelijkheid gaan bieden om abonnementen via de App te koppelen aan je smartphone dan is het probleem ook opgelost (dus via wallet met faceID zeg maar), maar dat kan hier dus niet.

Prima als dat NS only is om mee te beginnen, maar doe even iets moderns ofzo.

[Rickth64]

Nee, Tap to Pay is een Apple feature. De bank app zelf heeft geen toegang tot/interactie met de NFC chip.

[Stroper]

'k Hoop nu wel dat mijn banken niet stoppen met ApplePay en elk terug met eigen met zijn eigen, vaak minderwaardige, implementatie begint.

[Croga]

Op Android hebben veel banken juist hun eigen implementatie uitgefaseerd ten faveure van Google Pay. Wat doet je vermoeten dat ze nu op iOS het tegenovergestelde zouden willen doen?

[Bliksem B]

Dat denk ik niet. Je ziet juist dat steeds meer banken overstappen op Google Pay i.p.v. Android Pay. Dit zorgt namelijk voor lagere ontwikkelingskosten van hun App.

Behalve wellicht banken die meer gericht zijn op privacy?

[AceAceAce]

Google Pay is de tegenwoordige naam van wat vroeger Android Pay heette.
Je bedoelt overstappen van een eigen App met mobiele betaalfunctie er in, naar de Google Pay app die wat strakker geintegreerd is met het OS, de NFC chip, NFC Antenne, en eventuele Secure Element hardware.

Heb zelf 6 jaar in die markt gewerkt, inclusief de geflopte voorgangers van Apple Pay op iOS en Google Pay.

[Bliksem B]

Google heeft er toch clusterduck qua namen van gemaakt . Zie (als je gedesinteresseerd bent in de lore):

• Google Pay (payment method) - Wikipedia
• Google Wallet - Wikipedia
• Google Pay Send - Wikipedia
• Google Checkout - Wikipedia

Voor de overzichtelijkheid is er zelfs een diagram Template:Google payment apps - Wikipedia

Maar volgens mij heb je gelijk ja. Ik doelde op de manier van Android om een standaard betaal app in te stellen via NFC.

[supersnathan94]

Er is geen enkele Nederlandse bank meer die het zelf doet. Is allemaal GooglePay geworden.

[Soppyscroll]

Betekend dit ook dat je de NFC kan gebruiken op eigen NFC poortjes of toegangskaarten? (Icm wallet) Ik loop nu steeds met een druppel terwijl overige allemaal via mobiel gaan

[bjorn298]

Dit is mij ook nog niet duidelijk. Ik heb al veel gelezen, maar de focus van de meeste artikelen ligt toch meestal bij betalen. Heb wel gelezen dat de iPhone hiervoor Host Card Emulation moet ondersteunen en dat dat tot nu toe nog niet het geval was. Is er iemand die hier meer van weet?

[Reactie gewijzigd door bjorn298 op 15 augustus 2024 18:57]

[Soppyscroll]

Als dat er komt, maakt het werk wel een stuk makkelijker,

[Milian]

Hier (https://developer.apple.com/support/nfc-se-platform/) staat dat "iOS 18.1 will introduce APIs that support secure contactless transactions within compatible iOS apps using the NFC & SE Platform for in-store payments, car keys, closed loop transit, corporate badges, student ID, home keys, hotel keys, merchant loyalty and rewards, and event tickets, with government IDs to be available at a later date."

Dus het zal wel mogelijk moeten zijn, maar het is wel een vereiste om Apple de fees te betalen. Ik vraag me af of veel bedrijven dit zullen willen..

[vDorst]

Al ik het belangrijk vind, dat die gewoon open is, vraag me toch af of banken dit nu ook echt gaan gebruiken.
Net als we zien bij Android, banken stappen over op Google Pay API.
Volgens mij puur om kosten besparing en mogelijk andere features die ze anders niet voor elkaar hadden gekregen.

[RobertMe]

Wellicht banken niet, maar er is ook een andere kant. Het inzetten van de telefoon als betaalterminal. Dat bied Apple intussen wel aan aan betaalproviders, maar ook daar zijn weer kosten aan verbonden (incl transactiekosten?) wordt effectief een standaard component geopend waar de provider niks aan kan aanpassen, etc. Als bv een SumUp dat volledig zelf kan doen zitten daar mogelijk ook wat voordelen aan.

En daarnaast wordt de NFC chip dus volledig vrijgegeven, en niet alleen voor betalingen. En ik kan mij indenken dat bv een bedrijf dat alarminstallaties maakt die je met NFC kunt in/uitschakelen ook liever een eigen authenticatie protocol gebruikt en zich hierin niet wilt laten beperken door Apple. Dus zij zouden dan wel een app kunnen maken om een alarmsysteem met de telefoon ("fysiek") uit te schakelen i.p.v. dat dit met een los pasje moet.

En ik weet ook niet hoe uitgebreid de huidige NFC APIs op iOS zijn. Zijn er bv apps die de gegevens van een bankpas kunnen uitlezen? Of een ID kaart / paspoort? Of zijn die er niet doordat de iOS APIs dit soort zaken niet aanbieden? En en na deze "ontgrendeling" wel mogelijk is om dit soort apps te maken.

[supersnathan94]

Als bv een SumUp dat volledig zelf kan doen zitten daar mogelijk ook wat voordelen aan.

Juist sumUp heeft zich als een van de eersten aangesloten bij TapToPay. Sum up gaat dat helemaal niet zelf willen uitfigulieren. Misschien een CCV die een soortgelijke app ook al op android hebben (SoftPOS) en deze nu makkelijk kunnen porten, maar dat is dan juist weer een partij waar er dan ook wat op te verdienen valt. Heeft namelijk heel veel minder overheadkosten per transactie, waar een kleine partij als SumUP per transactie gewoon meer kwijt is aan maintenance en implementatie.

Die kunnen veel beter in een “pay as you go” (ja pun intended) model meegaan dan dat ze up front een bak geld moeten ophoesten voor eigen implementatie.

[m_snel]

Het lijkt me zeer onwaarschijnlijk dat je de chip low level kan programmeren, je zal gewoon gebruik moeten maken van mogelijkheden die Apple beschikbaar stelt.
Er zijn nog al wat iso normen waaraan de chips moeten voldoen. Dat is natuurlijk ook wel makkelijk want anders ging iedereen maar wat aanrommelen en kan je z’n ding verder nergens voor gebruiken

[Soppyscroll]

Wij gebruiken token icm alarm. Dus dat maakt voor mij da extra voordeel. Ook deuren openen met token

[Freeaqingme]

Ik heb niets met/van Apple, maar vind het wel lichtelijk schandalig dat Apple hier dan weer geld voor vraagt. In Nederland hebben we al heel lang het concept van 'geen twee heren dienen'. Dat zie je bijvoorbeeld bij makelaars. Ofwel acteert een makelaar als aankoopmakelaar, ofwel als verkoopmakelaar. Maar je mag niet van zowel partij A als partij B geld vragen.

Het lijkt me goed als dat hier ook van toepassing zou zijn: Ofwel verkoop je een apparaat aan consumenten, en is het vervolgens aan die consument welke diensten die gebruikt, zonder dat een derde partij daar ook nog weer geld over moet afdragen. Ofwel geef je de apparaten gratis weg, maar kan je vervolgens volop derde partijen chargen als ze iets met dat apparaat willen.

[emeralda]

Google Pay op een iPhone?

[Haga]

Brrrrrrr, moet er niet aan denken.

[mutley69]

Apple vraagt dus blijkbaar wel geld voor die toegang buiten de EU. Dat hebben we in elk geval op een site in de US gelezen. We zullen zien hoe open ze gaan zijn in de EU, maar ik geloof dat ze weer een nieuw afpersmechanisme in het leven zullen roepen. En trouwens, waarom onderzoekt men op dezelfde zaken ook de andere smartphone en e-book leveranciers niet? Die gesloten stores en die gesloten delen verhinderen de vrije markt - waarom verdedigt men die liberale principes niet? (ik heb het dus niet voor die pseudo neo-liberalen, ze falen keer op keer - en hun dogma's passen ze heel selectief toe - ik kan daar rond IPv6 een schrijnend voorbeeld van geven waar mijn tegenspeler mr. De Croo was - zijn antwoord was gewoon monopoliebeschermd en totaal onwetend m.b.t. de implicaties. Nu 10 jaar na datum krijgt men de faktuur in heel de EU!).