Apple Pay wallet

[2026]

Umm, no. Thank bank needs your card number, they'll never start excepting some number that apple just made up.



It's a normal card not present transaction. Your card details are extracted from your wallet and sent to the acquiring bank (which will send it on to the issuing bank) for authorisation. The acquiring bank settles the merchant (the merchant involved is part of the transaction), and the acquiring bank is settled via interbank settlement from the issuing bank.

How does it know which bank is the acquiring bank? How does the acquiring bank know which merchant is to be settled?

For the transaction to take place, we need to know at least 2 accounts and an amount (lets simplify it to this for now, we can expand as we go through).

Apple will not provide card details to the merchant. Thus, it's implied the merchant must supply it's bank detail and the amount to Apple.

 

[whatwhat]

If that is the case it will never fly in South Africa. The banks will never ever do this.

Do you have a link for me?

Please stop trolling in this thread. It's very obvious you do not understand the Apple Pay system, yet feel authoritative enough to say it isn't going to work.

Rather just wait and see.

 

[Hush9300]

If that is the case it will never fly in South Africa. The banks will never ever do this.

Do you have a link for me?

I've added the link in the post you've replied to.

 

[2026]

Apple doesn’t save your transaction information. With Apple Pay, your payments are private. Apple doesn’t store the details of your transactions so they can’t be tied back to you. Your most recent purchases are kept in Passbook for your convenience, but that’s as far as it goes.

Keep your cards in your wallet. Since you don't have to show your credit or debit card, you never reveal your name, card number or security code to the cashier when you pay in store. This additional layer of privacy helps ensure that your information stays where it belongs. With you.

So, scan someone else's credit card details, then go on a fraud spending spree and it can't be traced back to you?

 

[recre8]

If that is the case it will never fly in South Africa. The banks will never ever do this.

Do you have a link for me?

From what I understand out of the keynote last night: The phone transmits a randomized number (almost like a one time password) to the POS terminal. I suspect what is happening: Your phone verifies your fingerprint and gets a unique token from some Apple server. The phone passes the token to the POS terminal. The POS terminal verifies it against the credit card processor. The card processor asks apple for the credit card information for the given unique token. Transaction is performed. Well, at least that's how I would do it.

Can't see any reason this won't work in SA, unless there is some piece of FICA legislation that blocks this. My Standard Bank credit card is contactless and I use it sometimes, but unfortunately, contactless in south africa is synonym with clueless mostly. At the very least, its good that there is finally a use for NFC.

 

[NeonNinja]

Very interesting concept...

Will see you in 2017!

 

[faniebraai]

How does it know which bank is the acquiring bank? How does the acquiring bank know which merchant is to be settled?

For the transaction to take place, we need to know at least 2 accounts and an amount (lets simplify it to this for now, we can expand as we go through).

Apple will not provide card details to the merchant. Thus, it's implied the merchant must supply it's bank detail and the amount to Apple.

After reading the link supplied above, I'm not so sure anymore. It seems that you can tap your phone on a standard card reader. I assume your phone will then provide the code to the POS, which is used to authenticate/authorise against your account. How the link between your card/account and the unique code given to the POS is made, I have no idea, the link doesn't explain it either.

Actually more unsure now after reading that link.

 

[faniebraai]

Please stop trolling in this thread. It's very obvious you do not understand the Apple Pay system, yet feel authoritative enough to say it isn't going to work.

Rather just wait and see.

Trolling? What makes you think I'm trolling? Do you know what trolling is?

 

[faniebraai]

From what I understand out of the keynote last night: The phone transmits a randomized number (almost like a one time password) to the POS terminal. I suspect what is happening: Your phone verifies your fingerprint and gets a unique token from some Apple server. The phone passes the token to the POS terminal. The POS terminal verifies it against the credit card processor. The card processor asks apple for the credit card information for the given unique token. Transaction is performed. Well, at least that's how I would do it.

Can't see any reason this won't work in SA, unless there is some piece of FICA legislation that blocks this. My Standard Bank credit card is contactless and I use it sometimes, but unfortunately, contactless in south africa is synonym with clueless mostly. At the very least, its good that there is finally a use for NFC.

Yeh, I've changed my mind after reading that link. I was wrongly under the impression that the code would be sent to the bank and not given to the merchant. But now I'm under the same impression as you, which is still plausible.

As stated before, it will be seen as a card not present transaction, which attracts higher merchant fees and liability still sits with the merchant if the transaction is disputed.

SA Reserve Bank are "forcing" the bank to use 3DSecure at least, as this is more secure, so less disputes. Cheaper interchange for 3DSecure which is motivating the banks to go that route rather.

 

[recre8]

After reading the link supplied above, I'm not so sure anymore. It seems that you can tap your phone on a standard card reader. I assume your phone will then provide the code to the POS, which is used to authenticate/authorise against your account. How the link between your card/account and the unique code given to the POS is made, I have no idea, the link doesn't explain it either.

Actually more unsure now after reading that link.

Mentioned a few posts ago: I suspect the card processor company will get the actual card details from Apple using the unique number. I can't see Apple NOT having your card details at any stage.

 

[faniebraai]

Mentioned a few posts ago: I suspect the card processor company will get the actual card details from Apple using the unique number. I can't see Apple NOT having your card details at any stage.

Me neither, which is fine. Kinda. Just one problem. If they have your card details, it means they have your CVV. AFAIK it's against regulation to store the CVV if you are not the issuing bank. That's why snapscan is in a bit of a pickle.

 

[Hush9300]

Mentioned a few posts ago: I suspect the card processor company will get the actual card details from Apple using the unique number. I can't see Apple NOT having your card details at any stage.

From what I understand, they don't. The POS/Card Processor would already be aware of your unique Device Account Number. The only parties privy to the card details are you and your bank.

The Device Account Number becomes your digital credit card number with the transaction-specific security code acting as an additional layer of security.

 

[recre8]

Me neither, which is fine. Kinda. Just one problem. If they have your card details, it means they have your CVV. AFAIK it's against regulation to store the CVV if you are not the issuing bank. That's why snapscan is in a bit of a pickle.

Possibly they send through the CVV for each transaction, meaning the CVV only "lives" on your device and not at the institution?

 

[ScrnScrm]

OK Lets try clear up the confusion. Firstly, Apple Pay is an acquiring service. This means that they maintain the network agreements with the banks to clear transactions. At this stage, they have signed deals with MasterCard, Visa, and American Express. However, they have set up direct settlement deals directly with the banks. In other words, as an acquirer, when a transaction reaches them for authorisation, and they have a direct relationship with the issuing bank, they will send the transaction straight there and bypass the three major networks listed above. This is their advantage - they have scale to directly negotiate with the big banks and bypass the three networks, essentially taking their 1.5% cut of the transaction. This had the big three very nervous, hence the reason they dramatically slashed the fee they charge Apple - they dont want Apple to go direct to all the banks and cut them out the picture.

Now - in the South African context, this is not as relevant as all South African BINS (The first six digits of a credit card) are cleared via Bankserve, and Bankserve take a cut for the network connectivity/interconnect. Only internationally issued Visa and MasterCards clear through their respective network switches. MasterCard and Visa make their money in SA on ineternational clearing, and annual license/card/BIN management fees. The opposition to Apple Pay is going to come from Bankserve, and to a lesser extent the PSPs (Payment Service Providers) like PayD that aggregate POS devices on their own switches to bypass network fees.

Back to the Merchant : the POS device will link with the Acquirer (In this case Apple Pay) just like any acquiring deal. Because Apple have effectively negotiated a killer deal with the networks, and have the abillity to go direct to bank for settlement in some cases, they are able to manage the margin/markup much better than other acquiring services and PSPs. This will enable them to reduce acquiring fees and shake up the market. In the South African context, they will be a POS choice available to a merchant, at a negotiated fee. If they are competitive, they will take off. The banks here wont stop it because they care more about swipes.

Finally, at the POS and its integration with the iPhone. The POS device has NFC as one option to gather card details. How the iPhone NFC works : its tokenises your payment card details using a public key, and passes this onto the POS device. The POS device passes the token onto the Apple Pay switch, where apple use the private key to unencrypt the token back to Card detail form. The fingerprint is used to authorise the release of the token via NFC. Once Apple Pay have unencrypted the card, it passes the normal auth check relevant to that BIN, and the same process followed for physical card swipes at the POS device (which of course remains an option). The good thing about Apple's approach is that they actual card number is never made known to the merchant, so no PCI DSS compliance is required across the data network or on the end user device, making security much easier to manage and audits much easier to pass. The POS device can keep the token for reversing the charge if necessary but without the private key, they cant do anything else with it.

In summary - what Apple have done with Apple Pay is very eloquent. Its very safe, its easy to use, it is tied back with a much more realistic release mechanism (Fingerprint), and because of scale, its going to be cheaper and reduce transaction costs across the board for all of us. It is also not tied into NFC only - expect "Apple Pay" payment options on all major ecommerce websites soon. Its going to give PayPal sleepless nights. Google will follow suit with their own acquiring service as well, and I imagine between the two, they are going to rule the roost.

 

[recre8]

From what I understand, they don't. The POS/Card Processor would already be aware of your unique Device Account Number. The only parties privy to the card details are you and your bank.

The Device Account Number becomes your digital credit card number with the transaction-specific security code acting as an additional layer of security.

They mentioned in the video the number is unique each time, and it expires in a few minutes? Would this work in the same way as those garage door openers work which have the rolling code?

 

[Hush9300]

They mentioned in the video the number is unique each time, and it expires in a few minutes? Would this work in the same way as those garage door openers work which have the rolling code?

The Device Account Number never changes, I don't think. The accompanying security code does.

 

[2026]

OK Lets try clear up the confusion. Firstly, Apple Pay is an acquiring service. This means that they maintain the network agreements with the banks to clear transactions. At this stage, they have signed deals with MasterCard, Visa, and American Express. However, they have set up direct settlement deals directly with the banks.

Back to the Merchant : the POS device will link with the Acquirer (In this case Apple Pay) just like any acquiring deal. Because Apple have effectively negotiated a killer deal with the networks, and have the abillity to go direct to bank for settlement in some cases, they are able to manage the margin/markup much better than other acquiring services and PSPs. This will enable them to reduce acquiring fees and shake up the market. In the South African context, they will be a POS choice available to a merchant, at a negotiated fee. If they are competitive, they will take off. The banks here wont stop it because they care more about swipes.

Correct me if I'm wrong, but I believe that only banks are allowed to provide acquiring services. Sure, you have switches in between (altech etc) but ultimately the acquiring part is a bank.

But even so, in south africa this would mean that the merchant would have to have a relationship with apple in some way?

This is a very big deal, I'm not sure if apple have the muscle to do this here, let alone a world wide solution.

 

[ScrnScrm]

Me neither, which is fine. Kinda. Just one problem. If they have your card details, it means they have your CVV. AFAIK it's against regulation to store the CVV if you are not the issuing bank. That's why snapscan is in a bit of a pickle.

The Acquirers charge two fees : a free for Card Present, and a fee for Card Not Present. The Card Not Present fee is higher because the risk is higher (for fraud). Simplistically, the CVV is there to verify Card Present. CVV is not a pre-requisite, it just results in the merchant paying higher fees. The merchant are not allowed to store the CVV to bypass paying higher fees. In the Snapscan instance, the app is owned by the bank and the CVV never reaches the merchant. The debate is whether they should be paying Card Present or Card Not Present Fees. Same applies for most of the mobile payment solutions that QR based (with the exception of MasterPass).

 

[ScrnScrm]

They mentioned in the video the number is unique each time, and it expires in a few minutes? Would this work in the same way as those garage door openers work which have the rolling code?

The token is dynamically generated per transaction.

 

[faniebraai]

You are quite wrong about some things here, so let me break it down piece by piece.

OK Lets try clear up the confusion. Firstly, Apple Pay is an acquiring service. This means that they maintain the network agreements with the banks to clear transactions. At this stage, they have signed deals with MasterCard, Visa, and American Express. However, they have set up direct settlement deals directly with the banks. In other words, as an acquirer, when a transaction reaches them for authorisation, and they have a direct relationship with the issuing bank, they will send the transaction straight there and bypass the three major networks listed above. This is their advantage - they have scale to directly negotiate with the big banks and bypass the three networks, essentially taking their 1.5% cut of the transaction. This had the big three very nervous, hence the reason they dramatically slashed the fee they charge Apple - they dont want Apple to go direct to all the banks and cut them out the picture.

Can I have a source for the above statement?

Now - (1) in the South African context, this is not as relevant as all South African BINS (The first six digits of a credit card) are cleared via Bankserve, and Bankserve take a cut for the network connectivity/interconnect. Only internationally issued Visa and MasterCards clear through their respective network switches. MasterCard and Visa make their money in SA on ineternational clearing, and annual license/card/BIN management fees. (2) The opposition to Apple Pay is going to come from Bankserve, and to a lesser extent the PSPs (Payment Service Providers) like (3) PayD that aggregate POS devices on their own switches to bypass network fees.

(1) Not true, not all BINs are cleared via BankservAfrica, some are cleared via MasterCard or Visa.
(2) No it won't. Bankserv don't deal with merchants. They are a clearing house, and as such only deal with transactions between banks. Not even PSPs.
(3) This is not what payD does. I work for payD. You might be referring to PayU, Paythru, Innervation, Nomad, etc, which are POS aggregators and provide POS services on behalf of the acquiring banks.

Back to the Merchant : the POS device will link with the Acquirer (In this case Apple Pay) just like any acquiring deal. Because Apple have effectively negotiated a killer deal with the networks, and have the abillity to go direct to bank for settlement in some cases, they are able to manage the margin/markup much better than other acquiring services and PSPs. This will enable them to reduce acquiring fees and shake up the market. In the South African context, they will be a POS choice available to a merchant, at a negotiated fee. If they are competitive, they will take off. The banks here wont stop it because they care more about swipes.

The banks here will most definitely stop this. This is sort at source which is not allowed in this country. A merchant can only have 1 acquirer. They may not have different terminals for different banks.

Also, acquiring transactions from merchants are an acquirer function. Who will pay the interchange to the issuier if the acquirer is cut out? A company like Apple cannot be an acquirer in this country, only banks can be acquirers.

Finally, at the POS and its integration with the iPhone. The POS device has NFC as one option to gather card details. How the iPhone NFC works : its tokenises your payment card details using a public key, and passes this onto the POS device. The POS device passes the token onto the Apple Pay switch, where apple use the private key to unencrypt the token back to Card detail form. The fingerprint is used to authorise the release of the token via NFC. Once Apple Pay have unencrypted the card, it passes the normal auth check relevant to that BIN, and the same process followed for physical card swipes at the POS device (which of course remains an option). The good thing about Apple's approach is that they actual card number is never made known to the merchant, so no PCI DSS compliance is required across the data network or on the end user device, making security much easier to manage and audits much easier to pass. The POS device can keep the token for reversing the charge if necessary but without the private key, they cant do anything else with it.

Agree about PCI, but the same devices will acquire normal contactless and card transactions so not a big win there in any case.

You seem very sure on how apply pay will work, will love to read the same source material than you have.

In summary - what Apple have done with Apple Pay is very eloquent. Its very safe, its easy to use, it is tied back with a much more realistic release mechanism (Fingerprint), and because of scale, its going to be cheaper and reduce transaction costs across the board for all of us. It is also not tied into NFC only - expect "Apple Pay" payment options on all major ecommerce websites soon. Its going to give PayPal sleepless nights. Google will follow suit with their own acquiring service as well, and I imagine between the two, they are going to rule the roost.

I'm sorry, but I don't agree with you on this. Yes Apply Pay will become a payment option as Google Wallet is today, but between the two they will most definitely NOT rule the roost, especially not in this country with our strict national payment system.