#gmturek
stoic crypt
Hi 😀
It's for a back end server, so probably web?
The gateway for the card reader is going to hit an endpoint on our server.
So we will be using the Python SDK.
carmine bridge
What is "the card reader" specifically in this case?
stoic crypt
It's custom hardware that our client is going to be making. My understanding is that it's using EMV to handle contactless credit cards and Apple/Google Pay mobile devices. It then will hit our endpoint to provide us with the card and other info.
EMV will provide the actual card number and Apple/
Google Pay a token.
I only have experience using the Android/iOS Stripe SDK, which is what we currently have implemented (and captures nightly on the server).
carmine bridge
So it sounds like you need to handle raw card information and supply it directly to our API from your server? Meaning you're fully PCI compliant on your end?
stoic crypt
Right. Unless only using tokens from Apple/Google Pay and 3rd-party tokenization for the contactless card numbers before it gets to us would avoid that.
I'm mainly wanting to verify that this type of flow works with Stripe. We want to continue using you as a payment processor.
carmine bridge
I'm still not 100% clear on the flow, to be honest. What specific data do you want to provide to our API to make a Payment Method?
stoic crypt
We would provide the actual card number from contactless cards or the tokenized card number from Apple/Google Pay.
carmine bridge
When you say "tokenized card number" you mean the DPAN, right?
The dynamic PAN generated for the specific Apple Pay/Google Pay device I mean?
stoic crypt
Yes. I had to look up DPAN. I think that's Samsung Pay.
carmine bridge
If I understand you correctly, you can create a Payment Method using raw card data by supplying it here: https://stripe.com/docs/api/payment_methods/create#create_payment_method-card-number
You would be handling raw card info though, so you would need to be PCI compliant, which is where I think I'm misunderstanding something since you said something about a third-party in there somewhere?
stoic crypt
Yes, that would work.
We're looking into PCI compliance. I don't know if using only DANs would avoid that.
If we need to be PCI compliant, that is fine.
carmine bridge
DPANs are subject to the same PCI compliance rules as regular PANs.
stoic crypt
Thanks. That was one of my questions.
My understanding is that there are 3rd party services that will tokenize cards for you, but I'm not sure how that works yet. We might just hash the card number instead. But it sounds like we will need to be PCI compliant.
Do you know if the same pm_# is returned each time you supply the same card number/DAN, or is it different each time?
carmine bridge
Yeah, if you're dealing with raw card info you're going to have a significantly higher PCI compliance burden.
stoic crypt
Right, our client is aware of the PCI implications and is fine with that.
carmine bridge
It's different each time. You can use the fingerprint to see if two Payment Methods are for the same underlying card: https://stripe.com/docs/api/payment_methods/object#payment_method_object-card-fingerprint
stoic crypt
Oh, thanks, that is great to know, about the fingerprint. We could keep using the same pm_# each time, for repeated payments that we bundle, though or not? If we have a table linking PANs/DANs to the pm_#s?
With the mobile apps, we create a payment intent and bundle payments up until they meet the authorization. Then we do a nightly capture.
stoic crypt
Oh.... We have customer objects in the apps. So in this case, we would need to create a new payment method each time and use the fingerprint to match them if needed.
carmine bridge
Why is that?
stoic crypt
We won't be attaching them to customers.
carmine bridge
If you want to reuse them why not?
stoic crypt
We actually may not need to reuse them. It's for laundry. If we create a payment intent using a payment method with an authorization of $20. The customer could do 3 loads of laundry for $5 and it would still be under the authorzation for the payment method. We could then capture the payment intent at night for $15. We would just need to keep track of the PAN/DAN and what payment method/intent it relates to.
The client doesn't want to collect customer info with this payment flow.
I think something like that should work, right? It's similar to what we do with the mobile apps, but in that case we keep the payment methods attached to customers.
In this case they would use their contactless card or Apple/Google pay device for each purchase, but it would only actually be one payment (up to the auth, and then we would create a new payment intent, etc.)
carmine bridge
Yeah, that makes sense, but I don't understand the part about keeping track of Payment Methods and checking fingerprints and whatnot. Why not create a new Payment Method every time?
stoic crypt
I don't think we need to use fingerprints. We can make a new payment method each time we create a payment intent. We need to keep track and link card info to the payment intents/methods in order to bundle the purchases. Otherwise, there are Stripe fees for every laundry purchase.
Multiple laundry purchases would be under each payment intent/method. Once the authorization is exceeded, a new payment method/intent is be created.
On mobile, the only difference is that we resuse the payment methods each time we create a payment intent. There would be no need to in this case. A new payment method for each payment intent of bundled purchases is fine.
carmine bridge
Sounds good to me.
stoic crypt
Thanks for your help. I just wanted to make sure that flow would be possible with Stripe. And now I know it will plus the added fun of PCI compliance! 🤪