#resursa-sepa

1 messages · Page 1 of 1 (latest)

olive rune
#

@arctic walrus what are the issues exactly?

arctic walrus
#

Our current implementation flow looks like this:

  • customer adds sepa direct debit as his default payment method
    • FE collects the bank details and mandate
    • BE creates the setup intent (with usage: 'off_session' and confirm : false)
    • FE calls confirmSepaDebit method and it succeeds
    • customer has successfully attached the sepa pm with a setup intent & mandate for later use
  • customer later initiates a purchase on our platform for a new subscription with trial
    • BE creates a new subscription with trial (no pm added so that it uses the customer’s default pm)
    • subscription is created successfully, (no next step action required)
    • invoice with 0 is created and marked as paid
    • subscription is trialing
  • customer leaves the check-out process
  • trialing finishes & the next invoice is created & a new payment intent is automatically created
  • the payment intent immediately fails with "status": "requires_payment_method" & no associated charges
    • even though the customer has a confirmed setup intent with a mandate attached to it
#

Subsequently if I try from the dashboard to retry the charge we get a "This PaymentIntent requires a mandate, but no existing mandate was found. Collect mandate acceptance from the customer and try again, providing acceptance data in the mandate_data parameter." error

#

What would be the correct way to create a subscription with a trial and make it use the existing setup intent and mandate ?

olive rune
#

the payment intent immediately fails with "status": "requires_payment_method" & no associated charges
what's the pi_xxx or in_xxx Invoice where that happened?

#

my guess is you forget to set the PaymentMethod as default for the customer/subscription

arctic walrus
#

should I try to find an id from the past or re-create the flow again ?

olive rune
#

up to you! either works

arctic walrus
#

I did speed up the re-creation flow (by forcing the charge imediattely instead of waiting one hour)

the id is: pi_3Jp7w3FyRBjDqWnb1LSmv9kM

#

and I checked the logs and the user has that specific payment method from the setup intent as the default pm

olive rune
#

thanks, let me dig for a bit

arctic walrus
#

ok great no rush .. I need to go for lunch 30min-1h

olive rune
#

oh ok you're doing Connect with on_behalf_of

#

that was the most important part but you didn't mention it :p

#

the problem is the mandate you created via the SetupIntent only exists on the platform account, but you create this subscription using transfer_data and on_behalf_of (https://dashboard.stripe.com/test/logs/req_DI03sqsozFr8dy ) which means it's the connected account that would need a mandate to charge the customer

arctic walrus
#

so what you are saying is that setup intent needs to know who the mandate is for by passing the on_bahalf_of and it will match the subscription pi with the existing mandate

but our context is that we are setup as a platform with customers on our account, with multiple partners with stripe connect accounts

this means that the customer can buy out of a selection of products from different partners and we do not know before hand who will be the on_behalf_of (can be any of the partners and even all of them if the user purchases all the products)

olive rune
#

yep I knew you would say that :p

arctic walrus
#

😄

olive rune
#

ultimately the mandate has to exist on the merchant account you do the charge on

arctic walrus
olive rune
#

I think the only practical solution is to set that at the time of accepting the details via the SetupIntent as I mentioned, or defer collecting the details until the time of creating the subscription

olive rune
arctic walrus
#

I thought that on_behalf_of will create the initial charge to the customer from our main account and upon success create an additional transfer towards the connected account .

#

some docs even state more info like:

Using on_behalf_of:
Charges are settled in the platform’s country.
The fee structure for the platform’s country is used.
The platform’s information is displayed on the customer’s credit card statement.

#

so we being the platform ... are the ones that need the mandate to initiate the charge

#

and wouldn't our (the platform's) SEPA creditor id be used ?

olive rune
#

AFAIK the point of using on_behalf_of here would be that you want the connected account's SEPA creditor ID to be used and for them to be the merchant of record

#

create the initial charge to the customer from our main account and upon success create an additional transfer towards the connected account .
hmm no. That's just what transfer_data does, it says "process the payment, but then transfer X to Y account"

#

you can use transfer_data without on_behalf_of

arctic walrus
#

yeah ... that would solve this but would no longer render the invoices as being issued by the partner

olive rune
#

yep!

arctic walrus
#

btw .. our connected accounts currently do not have a sepa_debit capability activated .. but a normal flow for sepa purchases still works.

#

can you please check where is this mandate_1JoRZkFyRBjDqWnbujtOGqlN attached to ? our platform account or the connected one ?

olive rune
#

hmm, strange, I wouldn't have expected that to work

olive rune
arctic walrus
#

but that mandate did manage to process the charge

#

this one pi_3Jot0uFyRBjDqWnb1qlHg81A

olive rune
arctic walrus
#

ohh .. right .. one second .. I'll find the one I was looking for

#

pi_3JmYvmFyRBjDqWnb1w7SZXsy

#

this one wwas in a failed state and managed to recover it

#

with this mandate mandate_1JmZ0GFyRBjDqWnbs8mtfTjq

#

is the mandate in our platform or in the connected account (acct_1IyXzH2HKa4cyy4L)?

olive rune
#

yep you recovered it by going to the frontend to call confirmSepaDebitPayment it seems

#

that creates a mandate automatically

#

I think it creates the mandate on the correct merchant automatically in that case, I suppose

#

yeah internally that mandate is on_behalf_of acct_1IyXzH2HKa4cyy4L so I guess when the mandate is created client-side with our SDKs they do the right thing somehow

arctic walrus
#

so in the flow you suggested, where we would create a setup intent for every partner .. would that mean that the customer has 1 payment method with multiple setup intents attached or multiple payment methods each with an associated setup intent ?

olive rune
#

the latter

arctic walrus
#

and in this case a default payment method would not make sense right? I would need to specify to each subscription which pm to use ?

olive rune
#

ah, so a customer can be subscribed to multiple subscriptions that all operate on behalf of a specific connected merchant?

#

then yeah, I would use subscription.default_payment_method instead of customer.invoice_settings.default_payment_method indeed

arctic walrus
#

how would we know the details required for the sepa notification for a user ?
in the sources api there was this thing https://stripe.com/docs/sources/sepa-debit#using-webhooks-or-automated-emails

mandate[notification_method] = manual

we emit a source.mandate_notification webhook with all the required information to generate a compliant notification. On reception of this webhook you should notify your customer using the channel of your choice.

is there a similar mechanism with the payment methods api & setup intents so that we know the creditor id, mandate number and so on that are required to display to the user ?

olive rune
#

we send a compliant notification for you by default, to be clear, but you explicitly want to send/whitelabel this yourself?

arctic walrus
#

yes .. we have disabled all stripe emails and re-brand them ourselves

olive rune
#

then as far as I know https://stripe.com/docs/payments/sepa-debit#debit-notification-emails are the docs, you listen to the payment_intent.processing event and then you can retrieve any details needed. The creditor ID you should know since if you're doing it this way you are using your own IDs, for the mandate number and such, it's awkward to get at since you need the Mandate object which is only really returned on the SetupIntent(https://stripe.com/docs/api/setup_intents/object#setup_intent_object-mandate) so it's likely easiest to store the mandate_xxx in your database row along with the customer/subscription ID so you can look it up, or to store it in metadata on the Subscription object you create(and then you can access payment_intent.invoice.subscription when handling the event)

arctic walrus
#

about the creditor id ... we do not know it if we use on_behalf_of and like you mentioned :

1:06pm: AFAIK the point of using on_behalf_of here would be that you want the connected account's SEPA creditor ID to be used and for them to be the merchant of record

#

and this is the weird part again .. for the pi that we did manage it to make work pi_3JmYvmFyRBjDqWnb1w7SZXsy with the mandate mandate_1JmZ0GFyRBjDqWnbs8mtfTjq I do not know these details

#

because the account acct_1IyXzH2HKa4cyy4L does not have any sepa capabilities nor a creditor id

# 
 "id": "acct_1IyXzH2HKa4cyy4L",
  "object": "account",
  "capabilities": {
    "card_payments": "active",
    "transfers": "active"
  },
...
  "sepa_debit_payments": {
    }
olive rune
#

yeah that does seem odd, like I said I wouldn't expect it to work but maybe I don't understand what on_behalf_of does here. My guess is it works differently in test mode unfortunately

#

at least for cards you definitely can't do on_behalf_of without the connected account having the card_payments capability at least, so I expect it to be the same for other payment methods, so my strong suspicion here is it's a test mode quirk unfortunately!

arctic walrus
#

yeah .. that would make sense

olive rune
#

also sorry, have to run for lunch so can't answer anything further but my colleague @glossy stone can help with anything else!

arctic walrus
#

thanx .. enjoy lunch!

arctic walrus
#

I think we can close this thread ... thank you again.. bye 👋🏻