#rajat-recurring

1 messages · Page 1 of 1 (latest)

simple atlas
#

Quick question before I dig into your specific questions - is there a reason you're making these recurring transactions yourself, and not leveraging something like Subscriptions that we have built on our end?

tight hull
#

yes, because we would like to control when should we retry, and how often. The subscription billing platform doesn't allow the flexibility.

simple atlas
#

We do offer some customization on invoice payment retries - how much control are you actually looking to have?

tight hull
#

We would like to control date, time and number of retries for each customer. Its not pre-determined and based on our algorithm - when it tells us that there is maximum likelihood for payment to succeed.

simple atlas
#

I'm going to preface this by saying we do a lot of work behind the scenes for recurring subscriptions charges, and it's not something you can model exactly in your own subscriptions solution easily.

  1. You should be setting up your Payment Intents and saving the card for future off session usage.
  2. You should create future Payment Intents with off_session=true (https://stripe.com/docs/api/payment_intents/create#create_payment_intent-off_session)
  3. This goes into the nitty gritty of how our recurring payments work, and truthfully I don't know for certain. The intention of our APIs is really to hide this level of detail and we determine what information to pass back to the bank on our end. At a high level for recurring charges, we pass information back to the bank that indicates that a CVV shouldn't be needed. Using off_session=true should be enough to ensure that.
  4. If you're retrying off-session then you should be passing in off_session=true again, and that should mark is as recurring
  5. There's not specific timeline/frequency that you need for these recurring charges that I know of.
tight hull
#

Thanks Karbi. This was super helpful. So for the first transaction, we should be creating a regular payment Intent with the attribute "setup_future_usage" to "off_session" which will save the card for future use, right? Once, we create an off_session payment method, we should be able to use it any number of times to create an "off_session" transaction

simple atlas
#

Yup! that's the general idea!

tight hull
#

I see. I think at the moment we are not using paymentIntent to attach the payment method to the customer. We currently explicitly create and then attach the payment method to the customer ourselves which wont allow the payment method to be setup for future "off_session" usage. and hence a lot of our payments might be failing. Leveraging paymentIntent to create and attach the right payment method should hopefully solve that problem. Thanks a ton Karbi.

simple atlas
#

It just walks through how to save a card during payment

tight hull
#

Yeah, this is super helpful. Also, if we want to take a look at few our sample transactions and see how they the payload is configured i.e. what information is being sent to card networks for each of those transactions, is that possible to see? Not for all but just for a few sample of those.