#raimund_api

1 messages · Page 1 of 1 (latest)

willow wolfBOT
#

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

📝 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.

viscid plover
#

If you pass confirm: true along with your other create params you should get a different status

upper dust
#

That works, but I understood that this future usage thing should bypass this on the next payment with the same account. That doesn't seem to be true.

viscid plover
#

Correct, setup future usage and confirmation are separate concepts. SFU tells Stripe "during this specific confirmation, coordinate with the bank so that this payment method can be re-used". Intent confirmation is an action that needs to be done on all intents, it can be done automatically by Subscriptions but otherwise either you or your customer are initiating it

upper dust
#

Ah, so that bypass only applies if it were a regular payment with the same sum e.g. on every 1st of the month?

viscid plover
#

Not quite. Charging automatically is just a potential setting on a subscription, we don't charge automatically because of your setup_future_uage setting, we charge automatically based on your subscription's collection_method setting.

#

Setup future usage is entirely about whether or not to save the payment method at all and how to optimize what we save the PM for.

upper dust
#

Neither of these apply to us. You call us a platform. Somebody pays money into our system which they want to distribute to potentially several 100 recipients according to their provided services.

#

We never issue invoices in that sense.

viscid plover
#

Gotcha. Do you have a clear idea on how to move forward here? Happy to help clarify or answer anything that is still confusing

upper dust
#

Only if I understand correctly that since in our case payments are neither in a regular interval nor in a fixed amount we must collect this confirmation on every single transaction?

#

Bank account transaction that is.

viscid plover
#

Confirmation isn't a think you collect. I think the first doc I linked to might be illustrative here. Basically payment intents are a state machine. Providing a payment method is what moves the intent from the requires_payment_method state to the requires_confirmation state. Confirming the intent is what moves it past that state. It is a requirement in the same way that creating the intent itself is a requirement, if that makes sense.
https://docs.stripe.com/payments/paymentintents/lifecycle

#

And with Subscriptions, we don't automatically confirm payments because they are at a regular interval and price. There is just a setting on subscriptions that tells us we should try to pay invoices as soon as they are created. The invoice amounts can differ month to month, it is entirely the setting that tells us what to do after the invoice is created.

upper dust
#

I know the entry, but I'm also reading this:
"After the customer provides their payment information, the PaymentIntent is ready to be confirmed.

In most integrations, this state is skipped because payment method information is submitted at the same time that the payment is confirmed."
How does that second part work? Or can we not apply this to our flow?

#

OK, thanks about the subscription explanation. That part makes some sense. 🙂

viscid plover
#

Thanks for clarifying the disconnect, I have to tend to a couple other threads but will circle back in a minute.

#

Alright thank you for your patience. What that sentence is getting at is that we aren't doing the skipping there, that state is skipped because of how most integrations use our intents.

upper dust
#

So we aren't like most integrations.

viscid plover
#

This is really difficult to phrase. I am going to make sure we tweak that doc for clarity later.

#

Okay so maybe this may clarify. To submit the payment, these three steps need to happen:

  1. Create a payment intent
  2. Associate a payment method with the payment intent (this can be a new or existing PM)
  3. Confirm the payment intent
    These can be done separately, in pairs of two, or even all at once in a single API call. Basically the sentence you quoted is saying that steps 2 and 3 are usually paired together. As soon as you know you want to make a payment and which PM to charge, you usually just charge it.
upper dust
#

But we still have to perform the confirmation, no matter what, right?

viscid plover
#

Correct, I think you are trying to do all 3 of those at once.

upper dust
#

I probably misinterpreted this sentence:
"Authorisation is only required the first time you use a BankAccount object with the PaymentIntents API. After that, you can use the BankAccount object as a PaymentMethod to accept future payments."

Let me guess: "Authorisation" is not the same thing as the "confirmation" we've been talking about.

willow wolfBOT
viscid plover
#

Exactly. Here "authorization" means creating a mandate which is our way of logging that the customer approved you saving and re-using their payment method. Authorization happens during that first confirmation but is a different thing

upper dust
#

Thanks, I think I've got it now.

viscid plover
#

Awesome! Apologies for the confusion; I'm glad we could clear it up. I will reach out to our docs team about making the language here clearer.

upper dust
#

Thanks again. Maybe it's just me, but I simply mixed up the mandate and the confirmation; they sounded like the same thing to me.