#Logemann

1 messages · Page 1 of 1 (latest)

rose escarpBOT
rancid stone
#

Hi there!

#

How do you plan to integrate with Stripe? Checkout Session, Payment Element, PaymentSheet, something else?

steady sandal
#

So definitely no UI elements from Stripe or something. Like i said i want to trigger the payment via backend. Like when you return a scooter. You use their app, return the scooter and some time later, you get the invoice and your payment method is billed.

rancid stone
#

Sure, but how do you collect the payment information in the first place?

steady sandal
#

via the app. I add the payment details to stripe via endpoints after i got them via our app. We developed all screens ourselves.

#

So at this point. We are done with the screens for adding payments and also added this data into stripe via using stripe.setupIntents.create() and stripe.setupIntents.confirm()

#

( for SEPA and CC)

rancid stone
#

stripe.setupIntents.create() and stripe.setupIntents.confirm()
Thanks, that's what I wanted to know.

#

So when you confirm the SetupIntent, it create a PaymentMethod. And now you can create a PaymentIntent with that PayemntMethod to charge the customer from the backend.

steady sandal
#

yeah... thats what i hoped.. 🙂 right now we save the paymentMethod ID in our DB and will use this ID for further processing.

rancid stone
steady sandal
#

Thanks.... and can you tell me why i cant remove a SEPA payment method?

#

CC is no problem

rancid stone
#

What do you man by "cant remove a SEPA payment method"? What exactly are you trying to do? And did you get an error message?

steady sandal
#

stripe.paymentMethods.detach() on the PaymentMethod ID and the error is that it needs to be activated or something. Would need to check with dev to get more detailes about this

rancid stone
steady sandal
#

give me some time to figure this out. Thanks for the previous help

#

Will report back ASAP

#

We get this, even though we are quite sure that this payment method id exists:
{
"error": {
"code": "resource_missing",
"doc_url": "https://stripe.com/docs/error-codes/resource-missing",
"message": "No such PaymentMethod: 'seti_1LhVBPCHoir9yBu6s5IWWXZV'",
"param": "payment_method",
"type": "invalid_request_error"
}
}

#

**request id is: **
req_IHJFablAWB9hIp

rancid stone
#

Thanks! Give me a few minutes to look into this.

steady sandal
#

👍

rancid stone
#

Well seti_1LhVBPCHoir9yBu6s5IWWXZV is not a PaymentMethod, it's a SetupIntent, so it's expected to not work.

steady sandal
#

yeah... of course ... let me think about it, why we stored a seti_X instead of a pm_X

#

can you tell me the difference between await stripe.paymentMethods.create() and the intent/confirm combo: stripe.setupIntents.create() and stripe.setupIntents.confirm() . Which should i use in conjunction with CreditCards?

brittle flume
#

Depends what you're trying to do. Generally wouldn't recommend using paymentMethods.create()

#

Setup Intents will check if the card is valid, save the card to your customer and perform any bank requested 3DS/auth

steady sandal
#

ok... will always go the intent way then...

brittle flume
#

Definitely the better approach to prevent customer friction further down the line

steady sandal
#

Perfect. thanks.

steady sandal
#

One more question: how do we pass the credit card data in the confirm request... cant see anything...

brittle flume
#

How are you collecting payment data?

steady sandal
#

thats what i talked with your colleague in this thread no? WE collect data via our APP Ui and then for SEPA, we do intent & confirm (where the confirm holds the SEPA details aka IBAN) with Card, we cant supply the data in the confirm payload right but need to supply a pm_* id ?

brittle flume
#

Yes, but how do your customers input those credit card details to you? Which Stripe UI are you using?

#

Payment Element?

steady sandal
#

no stripe UI... we use our own UIs for that...

#

like Flutter UIs

brittle flume
#

Do you have the PCI compliance to handle raw card data?

steady sandal
#

hmmm. good question .Perhaps not

#

do we need that in germany?

brittle flume
#

This is why using our UIs (Payment Sheet if you're building a native mobile app) is critical as you've covered under our PCI compliance and they work directly with our payment APIs (Payment Intents, Setup Intents)

steady sandal
#

so ... do you have UI elements for flutter?

brittle flume
steady sandal
#

right now we dont use anything stripe related just raw Endpoints....

brittle flume
steady sandal
#

but the main problem is, that we will have backend based payment processing. So we wont have any direct payment user interaction. Just adding a payment method is has. a user UI

brittle flume
#

What do you mean by 'backend based payment processing'?

#

You still need a server/backend in most Stripe integration

#
  • Server creates the Payment/Setup Intent.
  • Returns it to client (web/mobile).
  • UIs to collect payment details.
  • Same UIs then use those payment details to 'confirm' the intent created by your server.
steady sandal
#

like i told your colleague.. we will have a payment processing like all those eScooter apps

#

but your flow is what we have right now

brittle flume
#

I've never used one so I've no idea how they work

brittle flume
steady sandal
#

so you use a eScooter and then their backend bills your card based in the rentout time

#

no UI interaction for payment like in an ecommerce shio

#

shop

#

the PCI compliant thing is an issue... but i dont see why your UI widgets are different than ours... its all about how the card data will be processed in the backend and sent to your servers or?

brittle flume
#

I understand there's no traditional payment flow for each transaction. You just want to be able to charge their payment method using MIT for each session (or whatever)

steady sandal
#

yep

brittle flume
#

But their needs to be a UI at some point to collect the payment data from your customers

steady sandal
#

yeah.. we have that custom coded UI

brittle flume
#

Ok, but then you're handling raw credit card data which requires PCI compliance

steady sandal
#

yeah... thats what you told me right... but then we need a addPaymentData sheet from your UI widget lib or something...

brittle flume
#

Our UIs are covered by our PCI compliance. If you use your own UIs for payment data collection:

If you continue to send card details directly to our API, you’ll be required to upload your SAQ D annually to prove your business is PCI compliant. SAQ D is the most onerous of all the SAQs, with over 40 pages of requirements you must implement to remain PCI compliant. We highly recommend you migrate to client-side tokenization of card information to substantially reduce the scope of your PCI compliance.

steady sandal
#

ahhh i get it...

#

thanks for the info about all this. So... looks its easier to use your libs 😉

#

UI libs

#

and they support SEPA and CC ?

brittle flume
#

Yes, very few Stripe merchants handle card data. It's an integration path we strongly discourage

steady sandal
#

and i can use your UI libs just for gathering payment methods... not required to use a UI for each TX ?

brittle flume
#

Has a breakdown of what PMs support which UIs. You're looking at Mobile Payment Element

steady sandal
#

will take a look and hopefully see something which works in my flutter env

brittle flume
#

I imagine you're scenario is something like:

  • Create an account.
  • Add payment details to be saved for payments.
  • Use account to initiate a session.
  • Charge previously saved payment details.
#

So the Setup Intent paired with Mobile Payment Element will take care of step 2 there.

#

Add then you'd use Payment Intents with the saved Payment Method from the Setup Intent for step 4.

steady sandal
#

exactly this!

#

We were nearly at the finish line before you told me about PCI 😉

brittle flume
#

Glad we intercepted this now then. Hopefully there's enough for you to work with there

#

Happy to answer any follow-up Qs

steady sandal
#

yep... no worries...

#

thanks for your incredible support

brittle flume
#

np!