#johann-muller_invoicing
1 messages ยท Page 1 of 1 (latest)
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.
- johann-muller_error, 23 minutes ago, 11 messages
- johann-muller_invoice, 19 hours ago, 84 messages
๐ 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/1252915348152520734
๐ Have more to share? Add details, code, screenshots, videos, etc. below.
hi! I think this is just not supported today, you can't use the two-step approach with Invoices(you have to confirm the invoice->payment_intent on the frontend directly), but let me check.
๐ฃ
yes it's not supported(Invoices don't use the same 'automatic payment method' system as raw PaymentIntents so aren't compatible). Mostly what I'd suggest as workarounds here are
- don't use a ConfirmationToken, just follow the official guide and confirm the Invoice PaymentIntent directly with Elements : https://docs.stripe.com/invoicing/integration?method=elements#accept-invoice-payment
- use ConfirmationToken but don't use Invoices, use raw PaymentIntents.
Thanks - let me check that quickly - our whole process is built around invoices so we're locked in that path.
why do you want to use ConfirmationTokens? to adjust the amount based on the payment method details?
Just the flow we have now is driving this and perhaps we need to talk to professional services for advice on this. Out flow is like this:
- Client adds services to cart
- The click checkout and if they have a save payment method we can just use create invoices with the saved method - works well.
- Client doesn't have saved payment method so we collect payment method and save token - keep in mind the client can still bail out here and that's fine because we have not created the invoice yet
- We go to server and do invoice items and invoice and send back pi
- We confirm (well that's what we hoped to do)
Looking at the docs you just sent it will mean that we create the invoice and then only ask then for their payment method. If they bail out now we're stuck with open invoices?
yes but you could void them on a cron job or something if that's an issue
was 99% there and was just about to crack out the bubbly wine ๐
I guess we can do that as well, not so clean but I'm sure it will work. Thanks for the help and information!!
the other option I suppose is doing this the 'legacy' way where you just create a PaymentMethod object with createPaymentMethod in stripe.js and pass that around, instead of the ConfirmationToken
I think we don't like you to do that because it becomes a lot more difficult to handle multiple payment method types and manage state between front and backend but maybe it's an option. Not sure if we deleted the documentation for this approach or not, looking
yeah I think all those docs were replaced by ConfirmationTokens. There's some stuff on waybackmachine like https://web.archive.org/web/20230427140807/https://stripe.com/docs/payments/accept-a-payment-deferred but the collapsible docs sections don't work so you can't read it. Mostly it's the same integration anyway, you just call createPaymentMethod instead of createConfirmationToken and pass payment_method when confirming the PaymentIntent.
๐ taking over for my colleague. Let me know if there's any follow-up Qs I can answer!