CaptainYarb - collect payment before invoice | Stripe Developers | Page 1

daring quiver May 17, 2022, 3:08 PM

#

Can you tell me a bit more about the behavior that you are looking for here?

#

Do you want to automatically charge your users and only send Invoices as receipts essentially?

frail narwhal May 17, 2022, 3:11 PM

#

I'm specifically focusing on the first payment and first invoice. After the first payment: Invoices and Subscriptions should continue as normal.

The behavior I'm effectively trying to work around is that I do not want to issue an Invoice to a Customer until after we've confirmed a successful payment. For my European customers an Invoice means they legally owe money. Only once a payment has successfully been captured do I want to handle the Invoice and Subscription.

zealous flicker May 17, 2022, 3:13 PM

#

Can't you do the PaymentIntent and Capture for the initial payment, then fall or call your subscription flow after you get a success back from the capture response?

frail narwhal May 17, 2022, 3:15 PM

#

I can, however it leaves the Payment disconnected from the Subscription and effectively forces us to forego an Invoice (acting as a receipt) all together, which is also required by European law.

daring quiver May 17, 2022, 3:15 PM

#

So you want to send Invoices for the user to manually pay after the first payment but you don't want to actually send that first invoice in an email before it is paid?

frail narwhal May 17, 2022, 3:18 PM

#

Essentially, yes. The problems I'm facing that :

I don't want to force the Customer into an obligation until they successfully pay.
I cannot avoid the Invoice being abandoned if I create one to make the payment, hide it from the Customer and prevent the email if they simply abandon the payment form.

zealous flicker May 17, 2022, 3:21 PM

#

this sounds like something we would be looking at in the near future.

daring quiver May 17, 2022, 3:24 PM

#

Gotcha. Trying to think of how you may accomplish this.

frail narwhal May 17, 2022, 3:27 PM

#

My current and incomplete solution:

Use the Invoice Upcoming API to calculate pricing
Create a Payment Intent for that amount
[Webhook: payment_intent.successful] Create Subscription Manually
??? Invoice voodoo magic ???

#

I could mark the invoice as void or paid out of band and set metadata on it so my custom solution could identify the payment, but that feels like the wrong solution.

daring quiver May 17, 2022, 3:35 PM

#

Creating a separate PaymentIntent (or even Invoice) and using it as a proxy for the other Invoice seems viable but yeah it does feel like we will want to keep the solutions to things that actually use the subscription if possible.

#

I am not thinking of good solutions for this at the moment. I will reach out to some colleagues to brainstorm.

frail narwhal May 17, 2022, 3:36 PM

#

We had originally built out a Quotes implementation and were ready to upgrade, but got stuck with "how do we handle abandoned payments".

#

@daring quiver You are a legend. Thank you so much for taking the time to answer my tough questions. It's sincerely appreciated.

daring quiver May 17, 2022, 3:39 PM

#

Oh I think I remember talking to you about that.
And thanks, always happy to help. I think a colleague might have to be the real legend if they think of a way to do this.

zealous flicker May 17, 2022, 3:47 PM

#

@daring quiver , could you create a feature request to the developers to maybe add in another parameter for subscriptions, maybe an extend a bool parameter or something that is like "Charge_initially_then_start_invoicing" or something to that affect.

daring quiver May 17, 2022, 3:48 PM

#

Of course, I can always put in feedback I just can't guarantee it will actually get added.

frail narwhal May 17, 2022, 3:50 PM

#

If it helps: the scope that this affects comes down to our Stripe Connect usage. We would have to manually assign the payment outside of the Subscription to attribute the payment on behalf of the other Stripe Account.

halcyon lily May 17, 2022, 3:51 PM

#

@frail narwhal we have many EU businesses using Subscriptions and Invoicing, I've never really seen someone say this and I wonder if there's a misunderstanding

#

you're always able to void an Invoice, there's no legal requirement for a customer to pay you

frail narwhal May 17, 2022, 3:53 PM

#

Is there a way to prevent the first Invoice email from being sent when creating a Subscription?

Also, what is a reasonable hook/flow to detect an abandoned invoice to void it?

halcyon lily May 17, 2022, 3:55 PM

#

If you use collection_method: 'charge_automatically'it's not sent until after the payment

#

As for the latter, you should use our incomplete flow, it's been the default integration path for months, you pass payment_behavior: 'default_incomplete' on Subscription creation. That way you control the first payment attempt and if they don't pay in 23 hours it just expires the subscription

frail narwhal May 17, 2022, 4:02 PM

#

🤔 hmmmm interesting.

Wouldn't that create a scenario where the Customer has a Default Payment Method which may be used automatically and in place of the Stripe.js integration we have?

#

It also looks like using collection_method: 'charge_automatically' would disable multiple European payment methods such as bancontact, eps, and many others.

#

As defined on the Create Subscription api docs for the payment_settings.payment_method_types attributes.

halcyon lily May 17, 2022, 4:08 PM

#

for the first question: no, that's the point of default_incomplete

#

for the second question: correct we don't yet support bancontact/sofort/ideal in that flow. We're working on it, but you'd have to use a SetupIntent first so that you get the SEPA Debit PaymentMethod, but that's still viable

frail narwhal May 17, 2022, 4:14 PM

#

💡 Ahah!

Would this be a reasonable flow?

Use Invoices Upcoming or Quotes to identify pricing before user "commits" to anything.
Use a SetupIntent to collect payment information for card or alternate payment methods
After user completes the SetupIntent via Stripe.js and clicks the "Pay Now" button trigger to send to our backend
The backend will attempt to complete payment by creating a Subscrption and using the SetupIntent as the payment method.
If it's successful, we've done it (high fives all around). If it's not we can immediately VOID the Invoice and let the user start back at #3.

halcyon lily May 17, 2022, 4:16 PM

#

and using the SetupIntent as the payment method.
that doesn't make sense no. But you can use the payment method created by that SetupIntent yes.

#

You could do that, that's just not what I would be doing personally. I'd do what I recommended earlier and skip the SetupIntent entirely

frail narwhal May 17, 2022, 4:19 PM

#

I'm not sure I follow based on your earlier recommendation. I got the impression that would disallow us from using multiple European payment methods such as bancontact, eps, and many others?

#

I get the impression I'm missing the blatantly obvious. 😅

halcyon lily May 17, 2022, 4:39 PM

#

That's the correct impression for now and that's still my recommendation since it makes the overall flow way easier. You can still use SEPA Debit for example

frail narwhal May 17, 2022, 4:41 PM

#

We do not plan to use SEPA as it can take upwards of 14 business days to complete the success notification. Again with consumer expectations that's an inappropriate solution. In a B2B world that would be normal. 🙂

halcyon lily May 17, 2022, 4:41 PM

#

I disagree with this totally too

#

sorry you do tend to make assertions as if they were widely true just because they don't fit your workflow

#

but okay in the case where you want Bancontact/iDEAL/Sofort for each invoice and don't plan to use SEPA Debit at all, the new flow doesn't fit you well I agree

frail narwhal May 17, 2022, 4:43 PM

#

My assertions are based off documentation available at https://stripe.com/docs/payments/sepa-debit

SEPA Direct Debit is a reusable, delayed notification payment method. This means that it can take up to 14 business days to receive notification on the success or failure of a payment after you initiate a debit from the customer’s account, though the average is five business days.

halcyon lily May 17, 2022, 4:45 PM

#

but that's not the same as you saying "This is B2B only" which is not true

frail narwhal May 17, 2022, 4:57 PM

#

Please do not inaccurately rephrase my statements. I've got genuine consumer-based constraints that I'm not presenting as they are not a concern of Stripe, nor am I criticizing you or Stripe for those requirements. Can we please remain focused on problem-solving?

halcyon lily May 17, 2022, 5:01 PM

#

Again with consumer expectations that's an inappropriate solution. In a B2B world that would be normal.
you did say this though

#

I'm trying to help you solve your problem, but I also need to separate the assertions about your own business model, payments in general and things you misunderstood too

#

earlier for example you mentioned you could never use an Invoice unless you were guaranteed the customer paid it. But I explained you could void it which seemed to fit your needs. But I almost didn't mention this because it seemed like this was a legal requirement you had that I might not be aware of (I don't know much about local compliance)
So I'm trying to split the different parts to make sure I understand what is something you can't work with, versus what is something you might have misunderstood

#

Out of curiosity: Would you use SEPA Debit on future recurring payments or you always want iDEAL and Sofort on every payment and the customer actions each one manually?

frail narwhal May 17, 2022, 5:13 PM

#

Our use case limits allowable delayed notifications to at most 48 hours for vouchers. Any digital payments need to have a near-immediate notification.

#

Wow, we're really miscommunicating here. This isn't a situation where I'm looking to "be right" or argue the semantics of the platform. I've definitely got a problem of understanding how to accomplish our goals, otherwise I wouldn't be in this support chat.

I have not dismissed any features or solutions and am committed to keeping an open mind about what solutions may be offered. A prime example of this is the subject of voiding an invoice, which I've been open for this entire thread. Wanting to avoid a behavior and taking the necessary steps to work around a similar outcome are worth discussing. That does not mean I can ignore ALL of my projects requirements or constraints, such as removing payment methods that we are literally switching to Stripe Billing to better take advantage of.

halcyon lily May 17, 2022, 5:17 PM

#

gotcha so even when we add support for iDEAL and such you won't really use it the way we planned where you get SEPA Debit for future payments. You want the customer to mostly action every invoice (unless it's a card payment)

#

So yeah collection_method: 'send_invoice' makes more sense for you, but you can't control when we send the invoice. It's basically on Subscription creation which doesn't really fit your need here

frail narwhal May 17, 2022, 5:19 PM

#

I'm specifically focusing on the first payment and first invoice. After the first payment: Invoices and Subscriptions should continue as normal.

halcyon lily May 17, 2022, 5:22 PM

#

sure but you can't get iDEAL/Bancontact/Sofort on the first invoice today unfortunately, not unless you use collection_method: 'send_invoice' which would email the invoice before the payment (which is behavior you don't want)

frail narwhal May 17, 2022, 5:23 PM

#

if I used the SetupIntent I couldn't I use collection_method: 'charge_automatically' along with default_payment_method to the stored payment method, which could include the aformentioned payment methods to avoid that behavior?

halcyon lily May 17, 2022, 5:24 PM

#

I don't think that can work for iDEAL/Sofort/Bancontact which is what you were after so no. I have to run though and @onyx gulch is taking over for me

frail narwhal May 17, 2022, 5:25 PM

#

Thanks for your help! 🙂

onyx gulch May 17, 2022, 5:26 PM

#

👋

frail narwhal May 17, 2022, 5:26 PM

#

Welcome! 😄

onyx gulch May 17, 2022, 5:36 PM

#

Just to make sure I have a good grasp on the current state - you're currently looking for a way to use 'send_invoice' Subscriptions, but not send the email for the first Invoice of the Subscription? And your main reason for doing this is because of the EU requirements where an invoice is an obligation for your customer to pay?

frail narwhal May 17, 2022, 5:43 PM

#

I need to take a step away for my lunch break. We can either resume this conversation when I return or I can re-open another thread. 🙂

#CaptainYarb - collect payment before invoice