#Zambo-charge-api

1 messages · Page 1 of 1 (latest)

trail pulsar
#

If you've already created Payment Methods and those are attached to Customers, then there's nothing to migrate. They can just be used as-is. If you're using the old server-side tokenization method with Sources, then you'll have to have your customers come back and add their payment details again in order to create Payment Methods.

Here's a guide on getting set up with Payment Intents that's geared toward getting off of Charges: https://stripe.com/docs/payments/payment-intents/migration

Migrating to the Payment Intents API
fathom quarry
#

Okay - we are using server-side tokenization, so we can either continue to use the legacy API to charge those users and have a separate implementation for new users with PaymentIntents, or we must have users provide payment details again.

#

Is it worth considering moving to a subscription-based implementation for this use case (a payment plan moreso than a subscription), or are we currently modeling this as intended by saving the payment method and handling the deferred payments ourselves?

trail pulsar
#

Hey! Sorry I missed this, I was juggling a lot of threads. Catching up here real quick

#

Is it worth considering moving to a subscription-based implementation for this use case (a payment plan moreso than a subscription), or are we currently modeling this as intended by saving the payment method and handling the deferred payments ourselves?
That will depend on if you want to build more on top of what you have and if there are any short-comings with your current setup. I can't really advise on how best to manage that while chatting on Discord, unfortunately. I will say that the model you described is possible on Stripe: https://stripe.com/docs/payments/installments

Accepting card payments in installments

Learn how to accept credit card payments using an installment plan with Elements and the Payment Intents API.

#

we are using server-side tokenization, so we can either continue to use the legacy API to charge those users and have a separate implementation for new users with PaymentIntents, or we must have users provide payment details again.
This is the way that most users seem to do it, where they keep the legacy system until the upgraded system is stable and (relatively) un-bugged.

fathom quarry
#

The concern on our end is less along the lines of not being able to complete the integration, it's really more the friction of needing to collect payment information again. This likely implies that we will have to maintain the legacy implementation for the duration of our installment plans, which is less than ideal but doable.

#

Thank you for the guidance!

trail pulsar
#

Of course! Let us know if have any more questions