I have two questions:
Is there a way to create an STPToken using Apple Pay without a payment? In my iOS app, the customer either enters in their payment info or decides to use Apple Pay when registering. When the customer decides to make a purchase (some time in the future after signing up), their card will be automatically charged. There is a method that I can call to check if the payment request can be made, but it seems that I have to actually run the payment and charge the card in order to get the token. Note that I can create a customer and saving a card without charging the customer if the customer enters in the payment info manually. This issue only comes about if the customer decides to use Apple Pay.
For testing purposes, when I do use the payment to create the token and charge the customer's card during the sign up process, I've noticed that the dynamic_last4 and expiration date fields do not match the actual card. I have verified this not just in my program, but also when I log into Stripe's website and check the customer's record. Although these fields do not match the actual card, I can indeed charge the card correctly. Are these fields being masked in some way by Stripe or Apple on purpose?
You need to invoke the Apple Pay payment process in order to get the Apple-generated token. While strictly speaking you don't actually have to process the payment to get the token, what would you do with it otherwise? Store it? They're not re-usable and you don't get the card details to otherwise store a customer/card pair from it for future token generation. If you're not already familiar with it, I would strongly recommend reviewing the Apple Pay Identity Guidelines doc: https://developer.apple.com/apple-pay/Apple-Pay-Identity-Guidelines.pdf with respect to offering your customers multiple payment options including Apple Pay.
Yes, with Apple Pay the last4/exp values are disassociated from the actual card for security purposes.
Related
I am new to the payment area in app. Say in an App like Ritual or Open Table, I want the end user to be able to pay to multiple payees (just like the two apps I mentioned that you can pay to any listed restaurants), how can I achieve that?
From what I understand, each payee could have an merchant ID. If I want to make payment to multiple payees, do I have to obtain all their merchant ID? Or do I collect payment and then transfer to each payees?
Or, is it as app developers, we pick a payment solution (like Stripe or Braintree), and ask the participating restaurant to provide their bank info for receiving payment, and when the end users are paying, they pay directly to the restaurant's bank account through the payment solution.
Thanks.
Not sure if I understand this, why do you need multiple payee? Isn't the customer would just pay he merchant? As long as you can get the merchant ID and their account number, there should not be any issue. No?
Never mind the question, it's basically what I described in the last paragraph of my question
Blockquote
As app developers, we pick a payment solution (like Stripe or Braintree), and ask the participating restaurant to provide their bank info for receiving payment, and when the end users are paying, they pay directly to the restaurant's bank account through the payment solution.
Using the iOS SDK for Stripe, can we do the following
Create a customer profile where the customer id can be sent and stored to the backend
Add, edit, delete credit cards to the customer profile
Card can be charged automatically from the backend
Note that, once the user make a payment via stripe, we ask them to allow auto-payment next time the balance goes below a certain level. So, it is not periodic subscription. But it is a permission in advance, to charge later.
For a single payment, the SDK takes the card info and provides the token. Token passed to server where the payment is finally process. This looks very nice and secured.
I do not want to store the card info in the iOS app, also not in server. But does stripe take the responsibility to store it and allow the backend to charge it later? I need a way so that server can communicate with stripe with a unique id and amount, so that stripe accepts the request and make the payment.
You can ask for webservice to your webservice developer which can make APIs to create customers in stripe account and store its customer_id in database so for next all payment you can make payment using customer id. Stripe will store card details in its database so no need to store card details at our side.
I have an application, that process payment to application owner.
When user clicks "buy" on an item, the checkout operation should authorize certain amount on the user's account until some date. And when that date comes authorized money will be captured from user's account to application owner's account.
There is also a possibility, that user may cancel this authorization through the application.
We are free to user Paypal API or Stripe. Which is better and how it could be implemented?
Yes , it is possible through paypal adaptive payment api.
I am not sure what does 'freeze certain amount on the user account' mean, but you can surely transfer the amount to a holding account(admin account) and then on the particular date you can transfer it to the owner's account, meanwhile if the user cancels the payment the amount can be transferred from holding account back to user's account. This option is there in paypal.
What you're looking for is a functionality called auth/capture. What you're essentially doing is authorizing the funds (holding them on the user's payment source) and then capturing them at a later time. This is the same premise as a hotel putting a hold on your credit card for incidentals, and later canceling the hold.
You can do all of this with the PayPal REST API. Here are the features you're looking for:
Authorizing funds: https://developer.paypal.com/docs/api/#authorizations
Capturing funds (at a later time): https://developer.paypal.com/docs/api/#captures
Voiding (canceling) an authorized hold of funds: https://developer.paypal.com/docs/api/#void-an-authorization
Here's the Ruby SDK that you'll probably want to take a look at using, to make the authorization process easier: https://github.com/paypal/PayPal-Ruby-SDK
A few notes here. With authorization, I believe the funds are guaranteed to be there for 3 days. You can continue trying to capture the funds for up to, I believe, 29 days, but the funds are not guaranteed to be there.
Hope that helps
I know that the iTunes Store stores client information, such as the client name and credit card information. Eg, if you want to buy a game, you have to log in using your apple account and provide credit card details. These details are already stored with Apple
I want to build an app that uses this credit card information stored with Apple to allow clients to make payments. Note: I do not want to use the in-app purchase model.
Does Apple provide an API that given the client username and password, allows me to access the credit card information and then make payments?
The idea is to build a charity donation app around this. But the in-app model does not support this.
In a nutshell, we basically want to use the existing iTunes infrastructure to build a charity donation app. Any ideas?
I have integrated paypal sdk in my application. The app get rejected from apple review team. They want information about account information, including passwords, in the Review Notes section of iTunes Connect App Information. Should i provide my paypal account details in Review Notes? Secondly if they use my paypal account to test , amount will be deducted from my paypal.
If you really need to, create a PayPal account for Apple to test with. You can deposit some minimal amount if need be. Once your app is approved, change the password.
Since the amount will be deposited in your merchant account, you wouldn't really loose the money. (You can also log in to your merchant account and refund the transaction if need be.)
NOTE: Do NOT give out your merchant account info; The transaction will fail if buyer == seller, and you really don't want to give anyone else access to your core business account anyway.