thomasnevink

[cunning void]

Hello! You shouldn't be handling raw card data like that directly: https://stripe.com/docs/security/guide

Instead use our payment UIs, like Elements, in your front-end to collect payment data in a PCI compliant manner

[timber trench]

I'm using payment-element in front-end and using stripe.js to make it PCI compliant

[cunning void]

Then what did you mean by 'real world card input'? If you're using the Payment Element in the front-end and have a working integration that creates payments all you need to do is swithc out your API keys from test to live

so that I can keep this as standalone and not tightly coupled with my frontside which is implemented in Angular?
To be clear, basically all Stripe integrations require a front-end component to collect and tokenise card data. You can't really decouple them

[timber trench]

So, basically from the backend or server-side I pass the clientSecret to the front-end who does the confirmation of payment right?

[cunning void]

Yep, exactly! If your full integration is working as you expect in test mode (using test cards), then there's nothing additional for you to do other switch your keys both server-side and in front-end

[timber trench]

But a test card is a string, so I was able to test it as standalone in my api side by assigning it to PaymentMethod of my PaymentIntentCreateOptions without getting any info from the front-end, I was able to save it for future use by saving it to a customer and confirm payment all in my web api.

[cunning void]

Ok, this is why I said you should have a fully functioning integration end-to-end including the front-end

The scenario you've tested isn't indicative of a real-world payment scenario (i.e customers entering payment details)

So if you're creating a Payment Intent and returning the client_secret to initialise the Payment Element you'd then call confirmPayment: https://stripe.com/docs/payments/accept-a-payment?platform=web&ui=elements#web-submit-payment

[timber trench]

Yh got you, creation of payment-intent is done on the server-side/ api while confirmation of payment is done in the front-end/ client-side right?

[cunning void]

Exactly

[timber trench]

Where do i handle save card for future use?

[cunning void]

You'd set the parameter that enables that (setup_future_usage) on the Payment Intent during creation: https://stripe.com/docs/payments/save-during-payment?platform=web#create-the-paymentintent

[timber trench]

How do I handle scenarios to check whether this customer exists and if yes check whether if this is an existing payment method and add it accordingly?

What I meant to say is there musn't be duplicate of customers, also duplicate of payment methods for the same customer?

[cunning void]

We don't prevent customer duplicates by default (i.e. we don't force uniqueness on name or email) so you'd need to implement that yourself. Maybe you lookup to see if a Customer exists with the email provided via this endpoint: https://stripe.com/docs/api/customers/search. And if one exists, re-use the ID and prevent creation.

Same generally applies for payment methods/cards. We don't deduplicate automatically, so if that's important to you you need to implement that yourself. You can check the fingerprint on the Payment Method object which is unique to a card number (https://stripe.com/docs/api/payment_methods/object#payment_method_object-card-fingerprint)

[timber trench]

ok

When I did my standalone web api, I had done this customers search which returns a customerId, I can do this along with my paymentIntent creation right for the real world case scenario?

[cunning void]

Yes if you're passing the customer parameter when creating your Payment Intent then you'll want to lookup for the existing Customer object before creating the PI

Then you can either pass the existing cus_xxx ID the search returns, or create a new Customer object if one does not exist with that email

[timber trench]

So before adding a PaymentMethod to Customer, during the creation of the PaymentMethod I'm setting the number, expmonth,etc is this pci compliant?

[cunning void]

You shouldn't be creaitng a Payment Method directly. The confirmPayment call in Stripe.js will handle that from the data input in the Payment Element

[timber trench]

Also, what you are saying is by default the same card won't be added again for a particular customer?

[cunning void]

No, we don't prevent the same card from being added multiple times

You need to implement that using the fingerprint field I noted

[timber trench]

Oh I see

Where can I check the fingerprint on the Payment Method object which is unique to a card number ? In the front-end?

[cunning void]

Yeah the integration gets a little more complicated now as you'd need to check the card details before you confirm the payment. You're likely going to want to use the deferred flow, which will let you create a PM object from the Elements data and then you can check the fingerprint and 'deny' the card: https://stripe.com/docs/payments/accept-a-payment-deferred

[timber trench]

Alright

[timber trench]

Lastly, where can I add Billing details?

[vernal dirge]

👋 taking over for my colleague. what exactly are you looking for?

[timber trench]

When doing a payment using PaymentIntent creation where can i add billing details?

@cunning void Thanks for the immense support ❤️

[vernal dirge]

https://stripe.com/docs/js/payment_intents/confirm_payment#confirm_payment_intent-options-confirmParams-payment_method_data-billing_details

[timber trench]

Ok thanks @vernal dirge

[timber trench]

Also, PaymentIntentCreateOptions accepts Amount as a long datatype, in real world scenarios this is a decimal no, is there a work around for this?

[vernal dirge]

the amount is in cents

so $1.25 is entered as 125