I want to have the customer enter their card info once and have a "pay now" button that will save the users info for future payments without them having to reenter there info and stripe says this can be done if you create them in a user object.
When the user is entering their info in and saving it in a user object where it saves on the stripe side, I dont understand how this is secure, even with tokens. Couldn't the developer add another function to go along with the stripe custom forms 'submit' or 'pay now' to send the card info somewhere else before or simultaneously while stripe is generates the token? And if I want, can I have the last four digits be displayed of their "current card" in my hybrid ionic app? Can someone please explain to me what I'm missing?
Im sending the customers payment token over the wire for a affiliate to process the payment (my apps only on the client side), and because share the token does not put the card at risk, are there any security concerns I should be aware about?
Yes, a nefarious developer could easily do whatever he wants with the customer's credit card information and that would have nothing to do with Stripe. Stripe and every other payment processor assumes that its developers/clients are not using their services for malicious reasons and I'm sure if such evidence surfaced their account would immediately be revoked.
Stripe's security model allows developers to trust Stripe to store their customers' credit card numbers securely for them so that they can focus on developing their product, not worrying about building a PCI-compliant credit card database store. The idea is you hand over a customer credit card number to Stripe in exchange for a token (customer ID) which you later reference when making subsequent charges to that customer's card.
As for the last 4 digits of the card, yes that is easily obtainable via the Stripe API
https://stripe.com/docs/api#cards
Related
Before migrating to the Payment Intents API the user's credit card payment was confirmed and charged on the server side using the token (received from stripe.createToken) after the purchase has been completed. This gave us the possibility not to confirm the payment in case any errors happens.
Now, with the Payment Intents API the payment confirmation happens already on the client side (stripe.confirmCardPayment) which is a problem in case an error happens on the server side while completing the purchase as the credit card has already been charged. A refund is not valid solution your Stripe fees won't be refunded.
How can we implement card payments with the Payment Intents API but confirm the payment at the final end of the purchase (as in the legacy workflow)? Or how can we prevent the credit card from being charged in case an error occurs during the checkout workflow?
Unfortunately, we couldn't find a solution to this problem in the documentation.
Help appreciated!
Here are the docs: https://stripe.com/docs/payments/payment-intents/migration
What you are looking for is modeled via "manual confirmation" of a PaymentIntent: https://stripe.com/docs/payments/accept-a-payment-synchronously.
It isn't Stripe's recommended integration. The recommended approach is to confirm client-side and listen to webhooks for payment confirmation.
This is because with manual confirmation, there is a higher chance of customer "drop off" where they authenticate your PaymentIntent on your webpage but close it out, meaning you lose your client->server roundtrip, leaving your payment unconfirmed (eventhough the customer thinks they authenticated hence paid).
Additionally, manual confirmation only works for card type payments, it is not supported for other payment methods based in other regions like iDEAL or SEPA Debit etc.
In our case, we wanted to authenticate the card payment at the end directly after making the charge. The Stripe support was able to help us with the following answer:
As I understand you would like to authenticate the payment at the end directly after making the charge. There is a solution to this, with the capture_method being set to Manual - https://stripe.com/docs/api/payment_intents/create#create_payment_intent-capture_method. What this would mean is, that the charge will be made and the user / client would be able to confirm the payment afterwards in the Dashboard directly.
This method is called Auth and Capture. Place a hold on a card to reserve funds now but only capture them after your business completes the service. When a payment is authorized, the bank guarantees the amount and holds it on the customer’s card for up to seven days, or two days for in-person payments using Terminal. You can find more information along with the API's under this Link: https://stripe.com/docs/payments/capture-later#authorize-only
When I create a subscription with stripe and the customer already has a default set payment method, I know how to confirm a card when it requires 3D Auth because I can look at the failure reason but what if a customer updates their card within the month...
How do I check if a new payment method requires 3D Auth when a customer already has an active subscription? And can I perform 3D Auth before the next subscription billing so it will work automatically without interaction?
You should use a SetupIntent to attach a card to a Customer (and also perform any authentication if required), when changing a Customer's card mid-cycle.
SetupIntent's will try to claim authentication exemptions for any future off_session payments (e.g. a recurring Subscription payment). There is still a chance issuing banks might still request authentication on the recurring payment, SetupIntent just try to reduce that chance, to address your point here:
And can I perform 3D Auth before the next subscription billing so it will work automatically without interaction?
In the case that the next recurring payment fails, you would have to bring your Customer back on session (to your payment page) and then authenticate the subscription.latest_invoice.payment_intent.client_secret with confirmCardPayment()
I am working with the Stripe API and I cannot find enough documentation regarding the on_session scenario.
I am saving the card after the first payment and setting the 'setup_future_usage' to 'on_session' because the customer is going to be always present in the checkout flow. However, this triggers authentication every time I try to pay something with the credit card number (4000002500003155). This type of credit card is intended to show only once the authentication process and to use the saved card for the subsequent off-session payment.
It's still totally possible that the issuing bank will require that you authenticate the future on-session payments. I don't think there's a test card to test the specific case you're trying to test though: https://stripe.com/docs/testing#regulatory-cards
Again I am frustrated by the lack of documentation involved in developing using Google Wallet as a payment gateway and I may switch to another service.
My new question is as follows:
Can I programmatically change the payment card utilized by a Google Wallet for digital goods subscription?
If a card utilized in a subscription expires, that is on the user, However, If I do not provide a means of changing the payment card elegantly, that is on me!
Does anyone know how this can be done? Or would I have to create a whole new subscription to produce this effect? This should be a basic feature of any payment gateway so I am assuming that I am missing something.
It should also be noted that creating a new subscription may be problematic without an ability to cancel the previous subscription via the API. Provided that both the old and new cards are still valid, it would attempt to process the payments for both subscriptions!
On a side note, why does it seem that the Google Wallet API is missing so many key features? (annual subscriptions, subscription cancellation, the issue mentioned above, etc...?)
Thanks again everyone!
If Google can't successfully charge, they'll send you a failure postback which you can use to evaluate what to do with the subscription.
It would be best if you don't equate Wallet to a "payment gateway" (or credit card processing service/gateway) because it isn't.
At the end of the day, Wallet basically gives you some "access" to a Wallet User's data. It's up to the Wallet users' to add/remove whatever payment instruments they have in their Google Wallet.
in Wallet for Digital, Google also handles the transaction - the processing part, so you're freed of any PCI compliance, and related payment infrastructure to get stuff going.
Instant Buy, Google will send you a "virtual card" for you to process the transaction using your own/existing credit card processor/gateway. In this case, you do have to be PCI compliant and have existing infrastructure.
In both cases, you don't have access to the actual Wallet users' payment data. Google locks that stuff down.
Hth....
This is the scenario I expect the system behave:
I have a platform where users can register and store their credit card information online, and with specific user's action, system automatically settles payment.
Of course, user expect automatic payment system as we said so when they enter their card information, and the purpose of this is to simplify the process when they decided to pay for something.
My question is this:
I found that Amazon saves user's card information when they purchased some products then user doesn't need to put all the card information again but just select from the list of cards he used and with one click, it finishes payment.
Also, in price line, I found that it automatically settles after bid accepted.
So I tried to find the provider or payment gateway company that Priceline or Amazon provide, and tried to find the way to implement the system at least, but couldn't find any. What I have found so far were like, using paypal, and it requires user to have paypal id
I'm doing this in PHP, can anybody give me some clue please?
Thanks in advance.
You should be able to do this with most payment gateways that support recurring payments.
Typically what you would do for new customers is capture their card details 'as normal' (via the payment gateway). The payment gateway will return a token id which you then store against the customer record
Next time that customer makes a payment you can submit the tokenised card number to the payment gateway
Since you mentioned Amazon, you might want to look at their payment service API: http://aws.amazon.com/fps/