I'm new to online payments. After some research, I wonder if Payment Gateway, by holding private key of Apple Pay Payment Processing Certificate to decrypt Apple Pay payload data, can hypothetically modify it (e.g. change amount) and send modified request to other relevant parties (Acquirer, payment network, issuer ...) then ultimately charge user more than what authorized
Definitely if possible, they would not ever do it due to legal, reputation issues...I'm just wondering if it's possible technically
Related
I have a third party API that connects directly to a restaurant's POS system. In order to pay for a meal, the API requires that I send credit card information through an HTTPS POST request so that it may be used to complete a payment.
I know not to save any sensitive details on the device itself or on a server that is owned by me. But without doing so, how can I safely request credit card details from the user, save them and then send those details over an HTTPS request in order for a transaction to be completed?
In other words, step by step:
1. User inputs credit card information in App
2. App sends credit card information using an HTTPS request to a third party API
3. Payment is completed
I need to securely gather the credit card information, and somehow save it so that if the user purchases multiple items, they won't have to enter their information every time they order.
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 a client who is dead-set on using PayPal for Credit Card processing. The application must be able to charge cards without the user entering the information every time. Digging around, I've found the Credit Card Vault feature, which would at least let me store credit card information for future use. Unfortunately, as far as I can tell, there's no JS based tokenization procedure in the RoR Paypal SDK gem -- in order to store data in the vault, the information first has to hit my server. Which means I have to provide PCI compliance.
Is there any way to tokenize a credit card for later use in Paypal that will let the token be valid indefinitely?
In the REST API they call it the vault and they have documentation specific to it.
In the Classic API it's called a reference transaction, in which case you would use Payments Pro (DoDirectPayment or PayFlow) to process an original authorization or sale transaction, and then pass that transaction ID into future calls to process payments with the card data PayPal has saved on their server.
If using DoDirectPayment you would use DoReferenceTransaction. If using PayFlow you would just change some of the parameters in the typical request to make it a reference transaction. The doc links above cover all of that.
As long as you aren't saving any card data on your server then the only thing you'll need to be compliant is an SSL certificate on your site, but that's becoming a recommended practice regardless of whether or not you're processing payments.
If you want to completely avoid hitting your server then you'll have to go with Payments Advanced, which embeds a PayPal hosted iframe into your site. I don't think it supports reference transactions, though, and it's a lot more limited than REST or Payments Pro.
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.
Having a bit of trouble with consumable in-app purchases.
Here's my setup:
I have an iOS client and a server. The server provides some kind of querying service (specifics irrelevant).
Each time the iOS client queries the server, I want to "consume" a consumable purchase. So basically, each search/query costs one consumable.
Here's what I originally thought of doing:
Client sends purchase request to StoreKit
StoreKit replies to Client with receipt
Client sends receipt and apple ID to server
Server verifies receipt and sends success to client
Client finishes transaction at StoreKit
Now for each query:
Client sends apple id (+ query data) to server
Server checks if given apple id still has remaining queries
Server replies to client with either query result or error if not enough queries remain for apple ID.
Now for the kicker:
I can't get the apple ID as it turns out. So I'm kind of stuck...
Does anyone have any experience with this? I could do it all on the client, but I want it to be secure.