#draesia.
lusty socket
Hi, let me help you with this.
It's hard to say since it depends how Subscriptions were created. In some cases the Payment Methods might be set up to be used with specific Subscriptions/billing period and might not be charged on one-off basis.
spark ether
How would I be able to decern between these two types of situations?
I believe a majority are created with the 'setup_future_usage' and mode 'setup', and the payment methods should be linked to the customer. However given some are quite old, not all of them may have this.
lusty socket
'setup_future_usage' and mode 'setup'
Those should be fine. What are other configurations?
spark ether
In the new system we just use Session with mode: 'setup' to collect the pm_xx
However in the old- there may be any combinations of configurations from years back; I definitely know some won't be able to be transferred, which is why I would like to somehow create a script to identify them
I figured so long as the Payment Method was attached to the customer, it could be used; but I guess not?
lusty socket
You won't be able to know 100% until a charge will be attempted. You should definitely account for those and be able to ask the customers to attach a new PM.
final vaultBOT
spark ether
Is this something that would be spotted using test data?
For instance, on our UAT server we have done the same steps as we will perform in a few days, on data which has been going a while too. Our tests seemed to indicate that it would work.
Is it possible that there are 'untestable' reasons for why a payment method can only be known 100% when a charge happens?
For reference, most tests are done using the 4242 card and the bacs_debit 12345 card
real scaffold
Depends what you mean by 'can only be known 100% when a charge happens'
What concerns specifically do you have? Declines? Authentiation/3DS?
spark ether
Yeah sorry I phrased that poorly. Yes we are concerned about declines which would have otherwise worked had we not cancelled the subscription.
For whichever reason
Mainly ones we can avoid by prior planning
Essentially I need to run through those 8000 subscriptions and group them into whether they should succesfully be able to take a payment or not come the 1st
When we migrate to the new system, it correctly cancels all the subscriptions, and uses their method successfully to create a Payment Intent.
However I'm worried there may be more factors with the real data we're not accounting for.
real scaffold
I mean that's generally impossible to know ahead of time. You can check the validity of the card details you have via a Setup Intent to save and optimise the payment information for future payments, but there's no way to know of other declines (such as insufficient balance etc) without just charging the card
spark ether
Yep so the other declines are fine, as they would happen if they still was a subscription anyway.
'You can check the validity of the card details you have via a Setup Intent to save and optimise the payment information for future payments'
This sounds interesting, could you explain a little further? It sounds like you're saying you could attempt to use the pm_xxxx details to create a new Setup Intent (which wouldn't need reconfirming), which would further verify the pm_xxx ? Am I understanding that correctly
real scaffold
Will the likelihood is that would re-trigger a 3DS challenge flow which would require your customer(s) to be on-session to handle the authentication
spark ether
Is the 3DS re-triggering also likely to happen if we don't do this? And attempt to continue using the method as planned?
real scaffold
Hard to say really, as it's all dependent on the bank and how you setup/created the pm_xxx objects initially
spark ether
Is this something I can check?
real scaffold
In all likelihood, you're likely going to need to prepare for the situation where a number of payments are declied or auth/3DS is requested and bring those customers back on-session to re-collect payment details and re-attempt their payments
spark ether
Thanks for the advice! Here's hoping 🤞