#guy-mike_api
errant prismBOT
👋 Welcome to your new thread!
⏲️ We'll be here soon! We typically respond in a few minutes, but in some cases we might need a bit more time (e.g., server's busy, you've got a complex question, etc.).
⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can 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/1252215350011891752
📝 Have more to share? Add details, code, screenshots, videos, etc. below.
lavish fox
We don't automatically retry payments for send_invoice invoices no
fervent flint
Thank you @lavish fox
One more thing, sorry for scope creep. When the "due date" arrives for send_invoice, it is not automatically charged either, it has to be initiated manually via invoice pay api, correct?
We don't automatically retry payments for send_invoice invoices no
Does it also mean that it's not possible for "send_invoice" type to have any sort of automatic payment related activities, unless done via API "manually".
lavish fox
Correct, the due date is purely aesthetic
lavish fox
> We don't automatically retry payments for send_invoice invoices no
Does it als...
We don't initiate payments for a send_invoice invoice. They're either:
- Paid via the customer when the visit the invoice page
- Paid hen you manually pay the invoice by confirming the associated intent (in a custom UI or something)
/pay endpoint is generally not recommended as it can't handle 3DS/auth flows
fervent flint
/pay endpoint is generally not recommended as it can't handle 3DS/auth flows
Ok thank you... This is something I did not know. We went with the "send_invoice" type because we wanted to "adjust" a previous invoice with the customer. But for that we needed to add a specific description on the invoice line, for each such case. The Invoice api has more granular control over it. Compared to "Quote", which we use otherwise.
Are the 3ds/auth flows handled better with invoice type of "charge_automatically"?
IIRC charge_automatically had no "due date"
Ok, sorry - you gave a finger and I am trying to take your hand. I got the answer to my original question. Just ten new ones pop up 🙂
lavish fox
Are the 3ds/auth flows handled better with invoice type of "charge_automatically"?
The type of invoice isn't really the issue. If you customer is deemed 'off-session' (as is with/payendpoint) and 3DS/auth is requested on the payment then it'll be a decline. The same is true for acharge_automaticallyinvoice if it's recurring/off-session
fervent flint
I see. So in the end of the day, it does not matter which invoicing type we use without the customers direct involvement. If they decide not to pay and they have a reasonable bank (providing 3DS) then it's a dispute department issue basically from this point on.
lavish fox
I don't understand that part
fervent flint
I guess it makes sense as well, if there was a malicious Stripe API user, they could bill customers for infinite amount of money
I don't understand that part
What I meant is that, 3DS requires customer's direct involvement. We are building a system where the customer gets an invoice on their e-mail that requires them to make an additional payments to their previous services which they used with us. They get an invoice stating that the due date is in 7 days. We were under the assumption that we can charge the customer if they somehow "forget" to do so.
lavish fox
OK, I didn't understand the dispute part