#unwrap_acss-mandate

1 messages ยท Page 1 of 1 (latest)

upper joltBOT
#

๐Ÿ‘‹ 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/1420797153080639508

๐Ÿ“ Have more to share? Add more details, code, screenshots, videos, etc. below.

dull folio
#

Hey there, if you're making API requests you can access the request-id in the response headers to share an example

#

The ID should also be in the error body in a dashboard URL

real bronze
#

Let me take a look if I can retrieve it quickly. I am implementing this using the Python SDK, so I'll bang out the whole StripeError exception and see if I can get it off of that object

upper joltBOT
real bronze
#

Here's one:
req_3puZs12qjcPNgT

#

I am going to lunch now, but I'll be back on this in about an hour. I don't want to do any unnecessary pings, so I'll just respond to this thread when I'm back.

#

Thanks for the eyes on this, y'all :)

dull folio
#

It looks like, as you mentioned, this PM already had a mandate collected that should support your payment.

#

I'm unclear why you're passing new mandate_options here for acss_debit since you want to rely on the existing mandate

#

Can you try removing those params?

real bronze
#

Oh, that's a good point

#

I hadn't even noticed I was doing so

real bronze
#

Still receiving the same error

snow robin
#

๐Ÿ‘‹ Hi, we had a changing of the guard, looking into the request for you ๐Ÿ™‚

real bronze
#

Pleasure to meet ya :) Appreciate it

snow robin
#

It looks like the setup_intent created by billing portal is passing some mandate options that might possible restrict the Payment Method to Subscription/Invoice usage. So this might requiring passing complete mandate options on the payment intent https://docs.stripe.com/payments/acss-debit#payment-schedule

real bronze
#

Ah, but the problem with that is that the actual person completing the checkout flow is not the customer

#

A representative of one of our actual "tenants" (our B2B business' clients) will be placing the order on behalf of the end customer using this payment method

#

The reason we implemented billing portal access for end customers was so that we could collect their online mandate data

#

This is the email response we received back in July when we were attempting to implement this feature. This response led us to give the end customer access to adding their banking information themselves, thus having Stripe collect the mandate data from them for us.

snow robin
#

Checking in with some of my team, appreciate the patience

real bronze
#

No worries. :)

upper joltBOT
broken spoke
#

๐Ÿ‘‹ taking over Discord. Give me 5 minutes to catch up on other thread and I'll look at yours

#

unwrap_acss-mandate

real bronze
#

Sounds great. Thanks Koopajah

broken spoke
#

@real bronze have you tried passing the Mandate id explicitly? ACSS Debit is a bit special here and the scheme has extremely strict rules around what payment schedules are allowed and such. So it can't just pick a "random Mandate" and you have to be explicit

real bronze
# broken spoke <@716058466774417548> have you tried passing the Mandate id explicitly? ACSS Deb...

The issue is that the mandate being already stored in Stripe I would expect it to be used, but I believe mossy had just said that the mandate data for that pm as it was stored after creating it from the billing portal potentially restricts the pm mandate for only subscription and invoicing purposes.
I could try and pass that mandate data explicitly, but it's a bit of a pain trying to retrieve an existing mandate object from Stripe given the payment method. I would have to do some pretty heavy data filtering on a SetupIntent.list() result.

#
<Mandate mandate id=mandate_1SBEzBFAed7s9c7sQNBQy5Xm at 0x10a9f8640> JSON: {
  "customer_acceptance": {
    "accepted_at": 1758806005,
    "online": {
      "ip_address": "10.36.3.99",
      "user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/14
0.0.0.0 Safari/537.36"
    },
    "type": "online"
  },
  "id": "mandate_1SBEzBFAed7s9c7sQNBQy5Xm",
  "livemode": false,
  "multi_use": {},
  "object": "mandate",
  "payment_method": "pm_1SBEz8FAed7s9c7sIFjGiT9t",
  "payment_method_details": {
    "acss_debit": {
      "default_for": [
        "invoice",
        "subscription"
      ],
      "interval_description": "when issued invoices become due | quand les factures \u00e9mises arrivent \u00e0 \u00e
9ch\u00e9ance",
      "payment_schedule": "combined",
      "transaction_type": "personal"
    },
    "type": "acss_debit"
  },
  "status": "active",
  "type": "multi_use"
}

This is the existing Mandate data for the payment method that was created when the payment method was added

broken spoke
#

Correct you have to do that filtering. Really we recommend keeping track of all Mandates yourself on creation as they happen for ACSS Debit, or create a new one for one-off payments

real bronze
#

I don't think we can retrieve that mandate data out of the billing portal in our own app, though.

broken spoke
#

what do you mean "out of the billing portal"? Like where did you find that Mandate then?

real bronze
#

I did that data filtering I discussed before. I was just trying to say that we can't perpetually store the mandate data ID on creation given that the creation occurs outside of our native application.

broken spoke
#

You can though since when those happen you get Events sent to your WebhookEndpoint right?

#

Really that is the way

real bronze
#

I suppose that's true.

#

We could create new mandate data for one time payments, but the issue is that the customer themselves are not clicking the button.

#

Thus we can't collect their IP address for the mandate

broken spoke
#

A Mandate isn't just an API parameter. It's a real customer consent, it has compliance rules attached to it. You definitely would need to get your customer back on your application and have them actively consent to the debit. ACSS Debit is really particular and strict with this

If this is an "off session" payment, then you need to tie it to an existing Subscription that the Mandate was approved for or create an Invoice instead of a one-off PaymentIntent otherwise

real bronze
#

So there is no way, without the customer themselves accepting the mandate at the time of payment, to use the ACSS debit method for one time PaymentIntents? The idea here is that we have collected consent from the customer to store and utilize their payment method (ACSS Debit) for one time payments ahead of time using the billing portal. Is that not in compliance with the standards set forth by the Canadian payments organization?

broken spoke
#

It depends on the Mandate(s) you already have. It's not just a "pass random Mandate id", that Mandate has to basically be crisp that you are asking to be allowed to debit whenever for whatever amount. ACSS Debit is the only payment method that comes with that concept of a "payment schedule"

real bronze
#

Yes, and we outline in the payment agreement that this schedule will be "sporadic" and utilized in this way. It seems like there's no sort of further configuration we can do on the billing portal side to change the type of mandate data collected, though.

#

The idea is that we collect the transaction_type: 'business', payment_schedule: 'sporadic' mandate upon initial payment method creation inside of the billing portal so that we have the customer information to report alongside that mandate.

broken spoke
#

yeah so in that case it seems like keeping track of the Mandate and passing that Mandate id is all you need to do

real bronze
#

But the mandate created by the billing portal is not the mandate we're attempting to collect.

real bronze
broken spoke
#

Gotcha, so in that case I do think you have to get them back on your own app to do this. Customer Portal focuses more on getting it set up for your Subscription/Invoices

#

ACSS Debit is... weird and complex. I kind of wish the Customer Portal didn't even let you add that payment method personally but was overruled

real bronze
#

Understood. Can we keep this thread open for a bit longer while I discuss with our stakeholders?

broken spoke
#

I can for a short time yes but we don't keep threads open long

real bronze
#

Understood. Give me like 30 minutes hopefully.

real bronze
#

Okay, just to recap:

  • We cannot use the customer portal to collect "sporadic" payment schedule mandates for ACSS Debit methods
  • We need the customer to accept this mandate
    • We could do something custom where we have the customer accept our custom mandate and we can store that mandate in our database to then use in the mandate param when we create 1-time PaymentIntents
broken spoke
#

yeah that would work

real bronze
#

Do mandates expire?

broken spoke
#

Hum it also depends on each scheme. I don't think so for ACSS per se but Mandantes can become "disabled/revoked" if the customer goes to their bank to their bank directly. BACS Debit for example has a flow where the bank says "you can't use this mandate anymore" and we send mandate.updated. ACH Debit has the same where after a failed payment it disables/revokes the Mandate

real bronze