Does this library generate tokens client side?

[0xpatrickdev]

Hi,

Thank you for all of the work on this. I've looked through some of the source code and the README, and am uncertain whether the token is generated on the client side.

It appears you are posting the payment details to the https://api.stripe.com/v1/tokens endpoint (documented here, which might be advised against in the docs. They recommend using Checkout, Elements, or the native ios/android libraries, since the tokenization is done in the client.

Am I correct in my understanding, or is there only a risk if I were to send the payment information to my server before sending it to stripe? I tried digging into https://js.stripe.com/v3/, but am uncertain wether they create the token the same way.

[jeff-da]

Hey! There's a couple questions here, so I'll do my best to answer each of them.

The token is generated on the client side; in the sense that everything is done in the client-side Expo application and you don't need to set up a server to generate tokens. This aligns with the way that Stripe normally does token generation (ex. in websites). Stripe recommends using Checkout, Elements, and the native ios/android libraries, and they are the easiest ways to generally integrate Stripe into an application because Stripe creates the UI and card fields for you. However, each cannot be used for their own reasons: Checkout needs HTTPS, Elements needs a DOM, and the native ios/android libraries require a native iOS/Android application.

You cannot send the raw card details to your own server. This module allows your application to stay PCI compliant by generating the card token on the client, which you can then send to your server to process the payment safely.

On another note, I'm working on integrating the native iOS/Android libraries with Expo right now (so you'll be able to import them via Expo). The main advantage to this is not creating Stripe tokens, but rather being able to integrate Stripe's UI elements in your mobile application (ex. Apple Pay and Android Wallet).

[0xpatrickdev]

Ok great, thank you for the clarifications. I think their documentation was a little bit confusing, but after doing some additional research and reading your answer I am OK on this.

And great to hear about the work on integrating the native iOS/Android libraries !

[0xpatrickdev]

Hey @jeff-da, I see you are no longer at Expo, but maybe you can still answer my question.

In Stripe's Integration Security Guide, there's a section that outlines what a developer needs to do in order to bc PCI compliant. Since this lib seems to be hitting the https://api.stripe.com/v1/ endpoint, doesn't this technically mean tokenization occurs on a server?

I realize that the server is not expo's or my own, but it seems Stripe strongly advises against this practice, and a business using this implementation would need to fill out a lot of paperwork:

My understanding could be incorrect, but please advise to the extent you can. As an aside, I also realize that Expo now suggests a different method for implementing payments, outlined here, but I am still curious for my own understanding.

Thanks !

[WeberJulian]

Hi, I'am also interested in the answer, I'd like to use this module but I have to be PCI complient. @jeff-da Thanks in advance

[rmp613]

@pcooney10 @WeberJulian Did you guys find an answer? Cheers

[andyhbg]

• Tokenization always occurs on Stripes server.
• If you use Stripe.js v1 or v2 you need to be PCI compliant

With version 1 and 2 you need to build and configure your own input fields when creating your payment form. This is no longer a valid way to handle credit card information since PCI Security Standards Council has changed the requirements. These require that businesses use input fields hosted by a payment provider.

With version 3 Stripe provides Elements and Checkout where input fields are managed on Stripes servers via iframe. In this way, it is enough that Stripe is PCI Compliant

[yilakt]

Wondering about this as well.