#matrixx_paymentintent-migration
1 messages ยท Page 1 of 1 (latest)
๐ Welcome to your new thread!
โฒ๏ธ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.
โฑ๏ธ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.
๐ This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1387474883104997510
๐ Have more to share? Add more details, code, screenshots, videos, etc. below.
Hi there. I'll be with you shortly. I'm assisting someone in another thread.
If you wanted to just collect payment method details in a PCI complaince way, yes the document you shared is our general guide: https://docs.stripe.com/payments/save-and-reuse
If you can share a step by step on what your business use case and what flow you want to build, I can further assist. Are you able to share more with me?
certainly...we are a community solar company that provides energy credits to customers. A customer will be invoiced each month for the energy that they use.
Currently, we have a web portal that customer's can log into to pay their invoices. We give them the ability to save their payment source details. We currently support credit card and ACH payments.
When a customer saves their payment source details, we submit the details to the Tokens API. This gives us back a token that we can use to refer back to the payment source in Stripe.
We then use the Sources API to attach the payment source to the customer.
These payment sources are prefixed with ba_ or card_
We've recently run into issues where customer's have payment methods created in Stripe first. These payment methods are prefixed with pm_. If we attempt to call the Charge API with a payment method that starts with pm_, we get an error message indicating that payment methods cannot be used with the Charges API.
This has created a need for us to upgrade our current implementation. We want to do it in a way that will allow us to continue to use Stripe with the historical payment sources our customers have, as well as allow us to create payment methods for new customers moving forward.
I am trying to determine the best way to move forward. I believe the Payment Intents API will work with payment sources prefixed with card_ or ba_, but it seems the only way that I can save a customer's payment details is by using the SetupIntents API, and from reading the documentation, it doesn't sound like I will be able to continue to use my custom form, but instead need to use the Payment Elements element to collect the customer's payment details? I was hoping to avoid this since it creates more scope (updating the front end).
๐ I'm taking over and there are a ton of threads and this is a loooot of words. I'll catch up in a bit. I got it @sick beacon you can delurk
matrixx_paymentintent-migration
We then use the Sources API to attach the payment source to the customer.
This is a bit minor but you are not using the Sources API based on your description. It's really confusing so not your fault here. Most people on my team mix this up too and I explain it all the time because I've been here a while
You are using the Cards API and the BankAccounts API. You do use the /v1/customer/cus_123/sources API endpoint which does have the source word in it but it's different from the Sources API which creates objects with an id like src_12345 so that's an important part at least
Ultimately, upgrading to support the PaymentIntent/PaymentMethod APIs is definitely the right call. We shipped those API back in 2018 and they are the foundation of our default/canonical integration path now.
and from reading the documentation, it doesn't sound like I will be able to continue to use my custom form, but instead need to use the Payment Elements element to collect the customer's payment details? I was hoping to avoid this since it creates more scope (updating the front end).
For card details that's correct. We deprecated the ability to build your own form/UI back in 2017 when we shipped support for our Elements library.
You are likely using our old Stripe.js v2 SDK client-side which still works but is discouraged. PCI rules changed at the time and required a higher PCI standard/requirements which is why we built the new flow/UI
Honestly using PaymentElement is likely your best approach here. It's really simple to use and it can support numerous payment method types well beyond card and ACH Debit in the future
Thank you for your detailed answer here koopajah!
It sounds like the PaymentElemet is the right way to go.
Out of curiousity, If we chose not to use the PaymentElement, and instead wanted to create the payment method via the PaymentMethod API, would it be possible to create the payment method, then attach it to the customer?
My main concern is that there is a note in the PaymentMethodService saying that the class is obsolete and will be deprecated.
Even if you create the PaymentMethod via the API you should use SetupIntent.
For ACH Debit for example you have to go through micro-deposits verification and on the PaymentMethod API this is done via SetupIntents. On the old BankAccounts API you first attached it and then you verified the micro-deposits.
For cards, you need raw card details access which puts you in the SAQ D requirements for PCI. That works but you should still use SetupIntent to properly support 3D Secure for example
You can use the SetupIntent API without PaymentElement, they are orthogonal to each other
how would I use the SetupIntent API without the PaymentElement?
When I reviewed the API docs, I didn't see anywhere the SetupIntent allowed you to pass the card details.
For ACH Debit you can refer to https://docs.stripe.com/payments/ach-direct-debit/migrating-from-another-processor#manual-bank-account-migration
We don't really have clean doc for cards because it's not allowed until you're approved because of the higher PCI compliance rules
Honestly I think you would be better off moving to PaymentElement for good. It is a much much better UI/flow, it supports many payment methods, we have our FinancialConnections product for ACH Debit in the US where users can connect their bank account, etc.
I know changing an integration is a hassle but it will likely convert much better
Thank you for your time koopajah, I will take your advise and implement the PaymentElements feature.