#jason_api

1 messages · Page 1 of 1 (latest)

versed crescentBOT
#

👋 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/1470929703060635730

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.

alpine skiff
#

Hi there,
let me read through what my colleague recommended. Can you clarify, what issues you are encountering?

#

I can't find a reference to a thread where my colleague koopajah was involved...

tall pond
alpine skiff
#

Ah yes just found it. Thank you

tall pond
#

hi vegvisir 👋

I have a legacy ACH account (ba_) that I am creating a mandate migration on. After the mandate migration succeeds, I do see an active multi use mandate attached to the payment method. I then go to create a payment using the payment element. I then see an inactive single use mandate attached to the payment method.

koopajah suggested that I remove the mandate_data property from the create payment intent API call. I've implemented that suggestion. I am still seeing the inactive single use mandate get created and attached to the payment method

we are using a two step confirmation process. I do see as part of the create confirmation token API call the mandate_data property being sent. I'm guessing this might have something to do with why it won't continue to use the previously created active mandate and insists on continuing to create an inactive single use mandate

versed crescentBOT
dull jolt
#

Hi! Give me a moment to catch up!

tall pond
#

no worries!

dull jolt
#

Caught up! I see you created an ACH payment method (ba object) via sources and then you used the ba_ object during the confirmation token creation. I also see there is a mandate data that is created. I just wanted to understand the exact issues you are encountering with this process. Is it causing an issue to make a successful payment?

tall pond
#

No, the payment succeeds. But the issue I am encountering is how to test that the mandate migration is successful. So I am using the following document to create the active mandate on the legacy ACH account

https://docs.stripe.com/payments/ach-direct-debit/migrating-from-charges?integration-path=payment-intent#mandate-acknowledgement

Later, when I make a payment using the payment element, the charge.pending event shows a completely different mandate ID. This in turn causes the mandate.updated event to get triggered. The previous status was active and the new status is inactive.

We listen to this event and mark the ACH account as unusable in our system. Based on koopajah's recommendation, to get the payment intent to continue to use the active mandate, I need to exclude the mandate_data property from the create payment intent API call.

I've done that, but the inactive mandate still gets attached to the payment method. I cannot find a way to make a payment, and have it use the previously active mandate that was created as part of the mandate migration.

Migrate existing bank accounts

Learn how to migrate existing bank accounts to the Payment Intents API or Checkout Sessions API.

dull jolt
#

Can you give me a recent payment intent object ID so I can take a look?

tall pond
#

Here are some logs describing the situation I am encountering:

req_rvJjvY0pkVNRmP <= create legacy ach account
req_RkjJTfXIBH1KXV <= perform mandate migration
we have an active multi use mandate attached to the payment method at this point (mandate_1SzQ5CFh7O2P26TzUhcqvzqI)
req_xOS6heqDSUAy9O <= confirmation token API call that has the mandate_data property included
req_LfK02LAOoYVEV6 <= create payment intent API call (notice the mandate_data property is not included)
evt_3SzQ6dFh7O2P26Tz1s2FeR4o <= charge.pending event that shows an inactive mandate was associated with the ACH account (mandate_1SzQ6eFh7O2P26TzTafAZXGK)
evt_1SzQ6zFh7O2P26TzqKtKjSai <= mandate.updated event making the active mandate, inactive

#

I would expect the charge.pending event to be using the mandate_1SzQ5CFh7O2P26TzUhcqvzqI mandate object, and I would not expect a mandate.updated event to be triggered from having made the payment

dull jolt
#

Thanks! Taking a look at them now.

tall pond
#

thank you!

dull jolt
#

Another quick clarification, why are you creating a confirmation token? This is just to make sure I get the full picture. Thanks!

tall pond
dull jolt
#

Got it! Thanks! Give me a while to just test this on my end.

tall pond
#

sure thing! take your time 🙂

dull jolt
#

Thanks for waiting! I am done with testing! Just typing my answer out.

#

I tested the exact same flow as you and below is what I believe is happening:

  • You created a offline mandate with Setup Intent which allows you to create an off-session payments [0]
  • Subsequently you tested it with on-session payment via Payment Element. I believe this basically creates a single use mandate which gets consumed once the payment is completed. Which is why it is a different manadate object, shows single use and is inactive.
  • If you are to test creating an off-session payment with the same ba object, you will actually see the original mandate that
    was created with the Setup Intent in the charge.pending event and also when you retrieve the charge with the py_ object.

[0] https://docs.stripe.com/payments/ach-direct-debit/migrating-from-charges?integration-path=payment-intent#mandate-acknowledgement:~:text=To create an off-session payment%2C you can use offline mandate acceptance to provide a record of your customer’s original authorization.

tall pond
#

Thanks for looking into this sam_stripe. I do see in the docs where it reads

In some cases, you might have pre-authorization from your customer from an earlier purchase or Setup Intent that you can use to create an off-session payment

So we do both, we perform offline payments, as well as online payments. I understand the method by which I created the mandate was offline, and that is likely causing the issue with the online payment.

Do you have a recommendation as to how I can create a mandate object that can be used for both offline and online payments?

dull jolt
#

Is there a reason why you need both online and offline mandates?

tall pond
#

To my understanding, a mandate is an agreement that the customer allows us to debit their ACH account. So it sounds like when they make an online payment, they are basically agreeing at that point in time so the mandate object is not needed? And it's only needed for offline payments?

dull jolt
#

Yeap pretty much. Since they are present during the online / on-session payment, they can authorize the purchase. But whne they are not part of the process for off-session payments, you need that pre-authorization from them.

tall pond
#

that makes sense. I still have a question about when making an online payment, the mandate.updated event gets sent and invalidates the offline mandate, but its getting pretty late for me here.

Is there any chance this can remain open and I can ping it in the morning? Or should I just create a new request and reference this one?

dull jolt
#

I can't keep it open but you can always reference to this conversation.

tall pond
#

Thanks again sam_stripe, you've been a huge help!