In my marketplace I have a requirement to:
Have a customer enter their card details
Once card details are submitted, process multiple charges against that card on the server side
I'm using stripe.js and creating a PaymentMethod on the client side using stripe.createPaymentMethod()
The ID of the PaymentMethod is posted to the server, which then does the following via the Stripe API library for PHP:
Retrieves the PaymentMethod from Stripe using the posted ID
Creates a Customer on Stripe, specifying the 'payment_method'
Creates multiple PaymentIntents, specifying the 'payment_method', the 'customer', 'save_payment_method' as true and 'confirm' as true.
I'm now wanting to handle scenarios where Stripe requires the use of 3D Secure.
Is there any way that 3D Secure verification can take place on the client, prior to the request to the server, whilst using stripe.createPaymentMethod() ?
If not, what alternative do I have?
It seems that a user completing the 3D Secure steps returns only a PaymentIntent. I don't believe I'm able to use this to make multiple charges against the card. This is whole reason for using createPaymentMethod() on the client in the first place.
Any ideas on how to go about this?
Is there any way that 3D Secure verification can take place on the client, prior to the request to the server, whilst using stripe.createPaymentMethod() ?
The approach to handle 3D Secure authentication on the client is to either use the confirmCardPayment [0] or handleCardAction [1] methods on Stripe.js. Unless you have specific needs, you would most likely want to use confirmCardPayment and follow this guide here:
https://stripe.com/docs/payments/accept-a-payment
I should note, that both these methods only work to process one payment at a time. In your case, you have multiple payment intents, so you would need to call either of the methods once per transaction. That is, if you have three payment intents you would need to call confirmCardPayment three times, repeating the last step in the guide [2] that many times as well.
This means that it is technically possible (but unlikely) that your users may have to authenticate multiple times to process each of their payments.
Unfortunately, there are really no workarounds for this. Even if you were to setup a user's card with SetupIntents [3] and charge them off-session at a later date, there is still a risk that you would need to bring user's back on-session to authenticate each individual payment intent.
All this being said, the majority of your users probably won't run into a scenario where they would need to authenticate multiple times in a row.
The only other option would be to create a single payment intent that covers the full cost of your product/service, which would allow you to call confirmCardPayment just once.
[0] https://stripe.com/docs/js/payment_intents/confirm_card_payment
[1] https://stripe.com/docs/js/payment_intents/handle_card_action
[2] https://stripe.com/docs/payments/accept-a-payment#web-submit-payment
[3] https://stripe.com/docs/payments/save-and-reuse
Related
I have a website similar to TaskRabbit (employers hire employees). I'm trying to figure out how to set up payments to work with 3D secure - even though I'm in the United States and I don't think that many cards require it.
The payment flow is
Employers go to the Stripe hosted Customer portal to enter their payment method, and if they need authentication when entering a 3D secure card, Stripe will handle that there
Employers will bid on shifts for Employees. Since multiple bids may be needed and not all bids would be accepted by the employee, I don't have any payment processing done at this stage
Employee accepts a bid. Now using the stored payment method, an off session Payment Intent is created. PaymentIntent looks like this
curl https://api.stripe.com/v1/payment_intents
-d amount=1000
-d currency=usd
-d customer = cus_ABCDEFGHIJKLMNOP
-d automatic_payment_methods[enabled] = true
-d payment_method = pm_1MYlwuGbdc
-d confirm = true
-d transfer_data[destination] = acct_1MVqZx2eFvmfdu
-d off_session = true
-d transfer_data[amount] = 100
And this works for a few test cards in Stripe but not for this one for example:
This card requires authentication on all transactions, regardless of how the card is set up.
Right now my website is not live. How likely am I to encounter problems in the US with 3D secure? Is my payment flow going to be possible (the main thing is I don't want the employer having to go through a Checkout process)
When you collect payment method details at first, you should use the Setup Intents API to properly set up the payment method for future use. For card payments for example you will be able to have your customer go through 3D Secure if it's required.
After the SetupIntent succeeds, you will get a PaymentMethod pm_123 attached to your customer which you can use on future payments either on or off session.
Now, even if the card is set up properly, it's still possible that the bank will decline the payment. It might be because they want the cardholder to go through 3D Secure again, but it might simply be that they have insufficient funds or any other reason.
When that happens, your code should handle the payment failure and get your customer back on session to enter new payment method details. It might be a new card, or the existing one but they go through 3D Secure again. And that payment can still fail, the same as any payment.
Finally, the test card you are using was explicitly built by Stripe to always require 3DS. It's not really something most banks would do, it's just an easy card to use for forcing any transaction to require 3DS in Test mode. But ultimately, it'd work the same as any decline: you get the customer back "on session" on your website/app and you confirm that PaymentIntent client-side instead.
I got a request as a developer to develop a bitcoin exchange site like https://mypatricia.co/ or https://instantcoins.ng/ I am to leverage on third party API like Coinbase, blockchain, it could be anything reliable API.
Users will be able to buy and sell bitcoin. For instance USER A makes an offer. USER B is interested in USER A's offer. When USER B clicks a button, with be a switch from USER A's wallet to USER B's wallet. Before the EXCHANGE is done. USER B is prompted to make payment in local currency.
I have been looking at https://developers.coinbase.com/api/v2#introduction https://api.blockchain.com/v3 I dont know how to go about it.
Is there any other better ones to work with?
There will be some other endpoints like
Where users get list of their orders
check wallet etc
I will appreciate your contribution
This is a very broad topic, so I'm just going to tackle few key points.
Dependency on third-party blockchain data
You can get rate limited
You might be a subjet to a man-in-the-middle attack
The source might (intentionally or unintentionally) send incorrect data.
The data is usually delayed
You'll most likely need to use another tool to create deposit addresses (since the third-party tools will allow you to create only limited amount of addresses on your account).
It's very risky and unreliable to use a third-party data. It's an industry standard to run a full node for each cryptocurrency you work with and access the blockchain data from your own node instead of a third-party API.
Escrowing the offered amount
As per your example, you need to make sure that user A is actually going to transfer the BTC. Since there are no smart contracts in BTC, you need to act as an escrow.
So you need to accept the BTC from user A to their deposit address (only your site should have the private key to this address) before you even allow them to pass their order into the queue.
Order list
Since you're going to be storing the order list on your side, you need to create a separate database and CRUD endpoints to maintain the order list.
currently I'm using the node stripe implementation
https://github.com/stripe/stripe-node
this implementation gives me error,
Sending credit card numbers directly to the Stripe API is generally unsafe. We suggest you use test tokens that map to the test card you are using
so I need to user stripe.createToken(); in order to do safe payment or need to configure the stripe account to allow unsafe payments which will be additional task.
how can I implement stripe.createToken(); with Node Js. I couldn't find any hints related to this. additionally only I have found stripe elements and JavaScript codes which can only be implemented from the front-end.
I couldn't
find any hints related to this. additionally only I have found stripe
elements and JavaScript codes which can only be implemented from the
front-end.
In almost all cases it is a bad idea to try to tokenize the card on your server side(i.e from Node). If you have the raw credit card number on your server, you open yourself up to issues with PCI compliance(see the section under Directly to the API) and potential attacks. That's one of the main reasons to use Stripe, it means that you don't need to store and process sensitive credit card data yourself, you just deal with tokens.
It's highly recommended that you always tokenize on the client side, using Checkouts or Elements. That way the frontend speaks directly to Stripe and your code never sees and sensitive credit card information. There are other advantages to using those technologies, such as improved fraud protection and supporting alternative payment methods such as mobile payments(Apple Pay/Google Pay) easily as well.
I'm creating a WebApi project that aims to handle payments in my project.
Actually, my approach is like:
CreatePaymentMethod(creates the payment, contact paypal and redirect the user to the payment page. If payment is done, redirect to PaymentApprovalMethod)
PaymentApprovalMethod (confirm the payment on my system, allowing the user to access the content)
What I'm wondering is... What if an users directly creates a message to invoke the PaymentApprovalMethod?
Suppose:
- CreatePaymentMethod is called, user sniffs with Fiddler the Transaction ID of the redirect
- Creates and adhoc call of the PaymentApprovalMethod like.
I see two possibles scenario to handle this situation:
Restrict (I don't know how) the calling of PaymentApprovalMethod to the messages from Paypal only
Cross Check the payment inside the PaymentApprovaMethod (ok, user, you said the transaction ID 123 is done, I'll contact paypal to verify this before trust this call)
The second one seems more safe but also more "time / resource" problematic..
Do I'm missing something? Is there something else I can do to avoid this problem?
Take a look at Instant Payment Notification (IPN). PayPal's system will POST transaction data to a listener script that you setup for all transactions on your account, be it a payment, refund, dispute, cleared payment (from pending), etc. You can use this to completely automate many post-payment procedures.
Part of your IPN listener will include a call back to PayPal's server to verify that the data actually came from them. You can then log IPN's separately, and only process verified IPN's, which means you know somebody didn't just POST directly to it on their own.
Some people do go a step further and only accept traffic to that script from PayPal's IP addresses, however, they do change their addresses quite a bit and I think that just becomes a hassle. The verification has always been enough for me.
IPN is definitely what I would recommend for you.
I want to use Stripe for payments, but want to be able separate the BIN/IIN from the 16 digit credit card number the user enters, before Stripe.js encrypts all the digits bar the last 4 ie. ******1457
Basically, I want to integrate MaxMind into the my Stripe powered payment page, and have MaxMind do a few checks on BIN matching before the transaction is captured by Stripe.
Stripe says this isn't supported currently, yet they do suggest using MaxMind for identifying PrePaid cards (which is done via BIN identification).
Any ideas what the correct answer is (hello Stripe:) and how to accomplish what I need?
Since you're using Stripe.js, don't overthink it. ;) This is just a matter of calling your own code before (or possibly instead of) calling Stripe's. Until you call Stripe.card.createToken, your form data is untouched.
Do note that, like Stripe does, you'll want to do the number manipulation client-side to avoid your server falling into PCI scope. An isolated BIN/IIN is not (currently) considered privileged data; you can pull it out with substring and then send that willy-nilly anywhere you like.
At that point it's a matter of deciding how durable you want your Maxmind integration to be. If you're not overly concerned with a nefarious visitor overriding your JavaScript, you could simply do the Maxmind check inline, before calling Stripe, via their HTTP API.
This is no longer possible with Stripe.js v3 (the previous answer was from 2013, and v3 was released some time later). This is because v3 is an iframe that is embedded on your page, and it is not possible for you to access the values in that iframe from your page.
In Stripe.js v2 this used to be possible, but actually even handling card details on the client side requires you to have an SAQ A-EP, rather than the slightly simpler SAQ A. Read more about it here: https://stripe.com/docs/security/guide#validating-pci-compliance
For the purposes of identifying prepaid cards, the Stripe API will tell you the card type in the API. If you really need the BIN, you can ask Stripe Support about enabling that for you in the response in the API.