#mayhul-subscription-migration

1 messages · Page 1 of 1 (latest)

cloud magnetBOT
knotty sun
#

mayhul-subscription-migration

#

Hey @worthy peak! How are you starting the new Subscription? Are you charging the customer immediately?

worthy peak
#

Yes, we are charging them immediatey and starting the sub using a subscription.create call

knotty sun
#

why? Usually when you migrate subscriptions you wnt to keep their previous billing cycle, not just suddenly accept a payment upfront.

#

But ultimately this is mostly expected, 3DS is required in many cases in Europe and you're a new "account/merchant" here, there's no history of you charging those cards

worthy peak
#

Fair, if there's a way for us to preserve the previous billing cycle I would take that as well.

knotty sun
#

I mean that's fundamental

worthy peak
#

I assumed that would be even more difficult to do so our plan was to reset the billing cycle and use credit to offset the difference

knotty sun
#

if someone paid 100€ yesterday for a year on the old account they do not want you charging them 100€ today suddenly with no heads up

#

You can also use billing_cycle_anchor or trial_end on Subscription creation too. There are a lot of ways to set up the Subscriptions as needed

worthy peak
#

How do the docs you linked get around the 3DS restriction?

#

Or will those have the same issue?

knotty sun
#

You're getting a 3DS requirement because you are incorrectly creating a brand new subscription that starts immediately and take a payment, and we assume the customer is on your website doing this and in that case you are expected to have them go through 3DS.

#

if you do one of the many options I called out, none of them take a payment upfront on session

#

If you set them up so that their next payment is next month for example, there's no payment no, no 3DS need. And next month the Invoice will be created automatically and the payment attempted off session (without any customer action) which allows claiming specific exemptions from 3DS requirement.

#

It's still possible they will have to do it on future payments and you'd handle this the same way you'd handle any declines

worthy peak
#

Got it, that's really helpful. I will look into using billing_cycle_anchor or trial_end to set up subscription rather than doing it immediately.

#

Is it more likely for the card to decline when we attempt an off session charge during the next month because we are a new merchant for the card?

#

I just want to manage expectations for our customer that we are migrating. If setting up these subscriptions in this way is just going to delay the 3DS failure to next month, I want to let them know to watch out for that.

knotty sun
#

yes it's likely you'll get a higher rate of decline, it's quite common, it's likewhen you change processor from Stripe to Paypal or vice versa

worthy peak
#

Do you have an idea of what the ballpark range is for 3DS decline during these changes? is it like 20-30%, 80-90%?

knotty sun
#

impossible to say sorry

worthy peak
#

Are there any docs on providing a good UX for offsession 3ds failures? I'm assuming right now what happens is that if their card fails next month, their subscription will be moved to past due and they will be prompted to re-enter credit card in our UI. But I'm wondering if there's a way on our end to JUST prompt for 3DS when their payment fails next month rather than requiring them to reenter their payment information completely

knotty sun
#

No specific docs for this, but this is definitely supported. What I'd build is a UI where you can enter new card details or use your saved card and let them pick