a.reit

[autumn arrow]

Not exactly, since you can't pay an invoice that isn't created yet

[sterile field]

Mhm - okay I see, is there any other way to achieve the expected behaviour?

[autumn arrow]

But you could, for example, collect a one-time payment separately, then adjust the customer balance so that the first invoice get covered automatically from that balance

[sterile field]

I was also thinking about that, but this one time payment would require and additional invoice, right?

Or can this be done without an invoice?

[autumn arrow]

You could collect with a payment intent, for example, no invoice needed

https://stripe.com/docs/invoicing/customer/balance

[sterile field]

Because if so, then we would have two invoices for one payment which is wrong from an accounting perspective

Ok so the worfklow would be via API:

1. Create Payment Intent with param payment_method_types = customer_balance
2. Amount will be added to the customers balance
3. Once the start date is reached, the invoice will be automatically set to paid by the customer's balance?

[autumn arrow]

payment_method_types = customer_balance -- no not this, you'd be using whatever payment method the customer wants to pay with

eg, card etc

then you need to adjust the balance for your business logic manually for this flow

[sterile field]

But I found another problem with that approach: The documentation says "The credit balance automatically applies to the next finalized invoice to a customer.". What if an one time invoice is created for this customer in the meantime? Than the credit balance would be used for that

[sterile field]

Ahh okay yeah you are right

[autumn arrow]

Ah, yea, that would interfere, and you'd want another approach

[sterile field]

But how do I tell Stripe via API to add it to the customer's balance? Or is this automatically done, when there is now invoice and just the Payment Intent?

[autumn arrow]

Since you're already using schedules, another option would be starting the subscription today and having them pay the first invoice, then putting in on a trial (no payments) until jan 1 (the next time to invoice them)

so they'd pay an invoice for 1 month today, but then not again until jan 1

note that the invoice period would be today through 1 month from today, eg nov 17 - dec 17

[sterile field]

which would be then confusing for the end-customer

because the actual subscription is starting in december and not in november

[autumn arrow]

Are you likely to see customer one-off invoices in the period before the first subscription invoice?

This is something we've heard and we're working on it, but the options I shared are the best work around until thats available

[sterile field]

I am not sure if I understand what you mean.

[autumn arrow]

The customer balance approach is relatively clean, with the potential end-case of another invoice using some balance (in which case the dec 1 invoice would require partial payment to cover)

[autumn arrow]

Refering to this

Are you using one-off invoices?

[sterile field]

Yes we are using one-off invoices

[autumn arrow]

OK, would you use one-off invoices for a customer that has not started their subscription yet?

[sterile field]

Ahh now I get it, thanks. Yes that is likely, as the customer i.e. purchases other one time products in that time.

with one time products I mean products without recurring prices, but with one time prices

[autumn arrow]

One other option then would be taking that payment, and instead of a customer balance you could apply a one-time 100% off coupon to the subscription to discount the first invoice

[sterile field]

But that would also then show up on the invoice, right? Which is also not a clean solution

[autumn arrow]

It would, yes

https://stripe.com/docs/api/subscription_schedules/create#create_subscription_schedule-phases-coupon

It would appear as eg:
amount $100
coupon 100% -$100
amount due $0
(then no payment taken)

[sterile field]

Yep - which will generate support requests on our customers side and eventually on our side.

Mhm - do you see any other way?

[autumn arrow]

Not really -- these options are all the workarounds I can think of until we make such a pre-payment feature available

I need to step away but my colleague @hard bone can help if you have other questions or want to explore one of the options in more detail

[sterile field]

Is there such feature planned?

[sterile field]

Am yes, I just tried the approach with the payment intent: I created one for a test customer: https://dashboard.stripe.com/test/connect/accounts/acct_1LIW4DB1zKCf85E8/payments/pi_3M5BkMB1zKCf85E80gCyiMim

But how can the customer access the payment intent and pay?

[hard bone]

Hello! I'm taking over and catching up...

[sterile field]

Ok I think it is only possible if the customer already has a payment method added, is that right?

Is there any way to make the paymentintent accessible via a stripe hosted payment form?

What about creating a charge?

Ok charge is also only working with a payment method attached.

[hard bone]

You can't take an existing Payment Intent and have someone pay it using a Stripe-hosted payment form. You can build your own payment form using Stripe Elements to pay it though. In a nutshell you would take the Payment Intent's client secret and pass it to the Payment Element: https://stripe.com/docs/payments/payment-element

[sterile field]

Ok so we have to build our own payment form