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.
Related
i want to save customer Card infromation for fruther use so customer don't have to fill the card infromation again and again. i am using, nextjs, stripe and nodejs.
How can i do that in a safe and protected manner.
Is there is any method to use the card infromation again and again for .
This has nothing to do with nextjs or node and its a bad idea to store customer data in your servers without proper PII practices and certifications in place.
Since you are using stripe, they provide a mechanism to store cards for off session usage - https://stripe.com/docs/payments/payment-intents#future-usage
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
Need some suggestions about how to handle operations in NodeJs. I have tried to search things but couldn’t find it anywhere, so I thought I will post it here to get the experts feedback.
We have built an E commerce platform using NextJS and NodeJS.
I still have to go test and do a load test confirming how do we perform, but I’m a little worried about all the statements and declarations about how nodejs is not a multi threading language and it is a show stopper and bla bla bla. So I am here to get your suggestion/feedback on what we are doing is okayish or not. This is what I have:
Authentication Microservice: for authenticating requests and finding if the user has access to a particular module
payment microservice: for accepting payments and refunds.
Shopping Service
MySQL and Sequelize
I will try to explain my question with an example of "order processing". So when I get a request to confirm an order, this is what I am doing to authenticate the request and confirm if details are full proof.
Confirm the request is authenticated through jwt token
Make a request to user auth and confirm user is a valid user and has access to order module.
Verify the price of items through database (because I’m assuming a payload can be hacked and wrong prices can be sent)
Verify if the discount is validated correctly from the database
Verify if the coupon is valid and the discount applied is correct or not
Check if the reward points sent are correct or not - a request to user service is sent
Our payment gateway is Razor Pay, here, we confirm if the payment id sent is a valid payment id, and the amount received from the user matches the total amount to be charged.
So this is a long list of validations we do at NodeJS right now.
It’s super fast on a single request. I will definitely tune things around when we go deep into load testing.... but my current dilemma right now is whether we have opted the right approach or not. Is NodeJS good enough to do this kind of execution. I am expecting no more than 200+ concurrent users in 6-7 months down the line so I am not toooooo worried about performance. I can do clustering and dockering to boost up performance. I want to know if I have made the right choice to do this in NodeJS. It’s not a very high cpu intensive algorithm, just some ‘for loops’ and some Database requests.
Should I keep this in Node, or should I move this code of algorithm in another service written in a different language like C++ or may be python.
Big time confused right now. Any help will be greatly appreciated.
Node.js may be single-threaded, but it should be fine with what you are doing. It is well suited for horizontally scaling/clustering and there are plenty of node modules already there to help you out with that.
https://medium.com/iquii/good-practices-for-high-performance-and-scalable-node-js-applications-part-1-3-bb06b6204197
Additionally, Node.js is asynchronous and can handle concurrent requests.
I have also included an older link on how to scale node.js that lists how many users each scaling method can help support. Long story short you can use vertical scaling, horizontal scaling, microservices(which it sounds like you already looking at) and automation to easily scale up your application. Node.js should work fine.
https://adrianmejia.com/how-to-scale-a-nodejs-app-based-on-number-of-users/
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
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.