#KRAKZ-Invoice

1 messages · Page 1 of 1 (latest)

clever lake
#

Yes, you can use Invoice API, to unify all those requests. Each request can be created as an Invoice Item. After all, you create an Invoice on that customer, it would contains all the open Invoice Items. Each Invoice will associate with a PaymentIntent, which results in 1 transaction on customer's bank

worn stratus
#

Hello @clever lake , thanks for getting back!

Based on the docs it seems that the Invoice only supports a single payment intent.

So we would like to reserve the funds on the customers bank account for every potential add-on service during the main service, to make sure we will be able to charge them in the end for everything. How is that possible?

So basically you order X service that takes 3 hours, during the 3 hours you might add additional smaller services (each being reserved on the bank account when placed) and we charge for the whole in the end.,

clever lake
#

I see

#

In that case, Invoice is not a suitable solution. Invoice is pre-payment. If you want to reserve, it would need to be inside a Payment already, hence results in separated Payment history as the original question

#

This is not common use case, but I do think you can have a work around of temporary create PaymentIntents without Capture aka put a hold, for every requests. Then after 3 hours you cancel all those PaymentIntents and create another one summing all the price and finally capture it immediately.

#

Capturing / Place a hold on Payments can lasts up to 7 days, so 3 hours should be possible

worn stratus
#

I see. Sorry I'm a layman to banking, but now I understand this is how it works.

The workaround you came up with is really smart but feels a bit too hacky for me so I'll try to arrange the requirements with the product owner.

I have an other question regarding invoices in this case. So if I create multiple paymentIntents for a customer for all the services, Stripe does not handle anything that might be required by our accountant department, that right?

So in that case we would create all the paymentIntents above, all being different transactions, and we would simply generate an Invoice in the end using your API that lists all the services previously purchased that we charged, and send that to the customer and accountant?

clever lake
#

Are you talking about the Invoice approach?

worn stratus
#

No, now I separated the invoice now from charging the customer. The invoice would just serve the taxing purposes (I don't know about my client's country laws but in our country we have to send the invoice to the customer as well)

#

So we charge the client with multiple payment intents, we get the money.

#

And now I create an invoice for taxing purposes (I suppose Stripe doesn't handle this automatically out of the box in some way?)

clever lake
#

Oh you want to create an Invoice just for the tax part?

worn stratus
#

yup, based on what I've learnt in our discussion

#

Invoice might not be the right term

#

maybe receipt?

worn stratus
#

@clever lake based on the docs I don't see a way to create receipts without an e-mail address https://stripe.com/docs/receipts

Do you know if that would be still possible somehow, and we would display the receipt in our app rather than sending it out in email? (our primary sign-in method is OTP using SMS, we might now always have the user's email address)

clever lake
#

Hi! Sorry I have been working internal for the Docs domain down problem

#

The PaymentIntent has a Charge object inside, it also contains the receipt link

#

Could you try to retrieve the url there and display on your app?

worn stratus
#

This is what I've found, but wondering if the receipt gets created at all without an email address?

#

(also note im on a test account which I think might act differently with how receipts work)

#

thats the only property related to receipt

clever lake
#

It's inside the data inside charges

#

this receipt_url

worn stratus
#

Found it!

#

Amazing, thank you!

#

Really appreciate your help and I mean it, must be tiring to work on the tech and provide tech support as well at the same time for a lot of people.