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.
Related
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
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 am creating a payment processing page for use via stripe and I want to be able to have my customers manages saved cards or use a new one. I am worried about being too forthcoming with some customer information and the possibility of exposing too much card information to my servers.
If I retrieve sensitive info like last 4, exp date, etc. should I be putting some means of encryption on it or is it completely fine to display or store pieces of that information for relationships server side on my end?
EDIT: New dev here be gentle :)
The only PCI-sensitive information is the entire card number and the CVC.
The card's brand, last 4 digits and expiry date are not sensitive. If you use Stripe, you can retrieve this information the card object's attributes, e.g. exp_month and exp_year, etc.
From a PCI compliance point of view, you don't need to do anything special to handle this data since it is not considered sensitive. My recommendation would be to either simply query the information from Stripe as needed, and discard it afterwards, or store it as-is into your database (in that last case, you'll probably want to use webhooks to make sure your DB is synced with your Stripe account).
In my app, I want users to be able to add money to their account, and send it to other members when certain services are rendered.
Is there a safe and straightforward to do this with Parse.com? If not, is there a third party someone can recommend?
Parse actually released something for mobile payment processing. It's called 'Stripe.' http://stripe.com/
SagePay's form callback can be hacked by re-using the success URL that the user is directed to upon a successful transaction. This can create all sorts of problems with duplicate transactions, fake transactions etc.
You can check for a duplicate VPSTxId, but these can be generated anew by hacking around the crypt parameter of the callback URL.
The crypt parameter can also be manipulated to generate a different "Amount" field.
I have not tested what other field values can be changed by hacking the callback URL crypt parameter.
Is there any way (as per PayPal's IPN validation) of doing a double-check callback to SagePay to ensure that the transaction is new and unique?
Thanks for your post. In general we encourage clients to use Server integration where they can. We also constantly monitor transactions for suspicious behaviour and proactively contact our customers if we suspect any malicious activity.
We recommend customers make sure that they’re using the latest version of our integration protocol which is currently v3. Get the latest integration documents.
As Dan suggests you could use the Reporting and Admin API to validate that a transaction does indeed exist on the Sage Pay side but having an additional validation mechanism (like PayPal's IPN) is something we will actively explore.
If you'd like us to update you on this, then please get in contact with our customer services team at support#sagepay.com or 0845 111 44 55.
Sage Pay Support
You should always redirect a user from a success URL.
I personally use a fulfil page (success url), and a thank you page. On the fulfil page, you should obviously only ever process a transaction once (based on the transaction id), and you can store crypt sent with a transaction. The crypt will have to be valid and is only possible to encrypt if you have the encryption key.
So hacking would be extremely difficult unless you are being very security lax, and the hacker would have to know your encryption key to even begin trying to hack it.
Alternatively, you should use the server integration, so that the communications are server-server, not client-server. There is little difference between form and server.
10 immutable laws of security
http://technet.microsoft.com/library/cc722487.aspx