mike_api

[frank hemlock]

👋 Welcome to your new thread!

⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always 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/1448534900948074546

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

[cosmic scaffold]

I believe you are on the right Doc for this change and yes, it means more API calls to get the desired information.

1. If you have Invoice Id then use List Invoice expands ['payments'].
2. If you have Payment Intent Id then use List Invoice Payment

regarding Charge and Invoice, do you mean there isn't a PaymentIntent exist between them? Could you give an example?

[upper coyote]

regarding Charge and Invoice, do you mean there isn't a PaymentIntent exist between them? Could you give an example?
Correct: My understanding is that using the old "Charges API", a merchant could create charges directly, instead of creating payment intents. When they did this, the charge would be placed on the invoice directly without a payment intent joining them.

This approach is frowned upon today, but I believe merchants on older integrations still do this.

This is alluded to in the docs too. Check this link: payment.charge says:

ID of the successful charge for this payment when type is charge.Note: charge is only surfaced if the charge object is not associated with a payment intent. If the charge object does have a payment intent, the Invoice Payment surfaces the payment intent instead.
So as you can see, the docs even say that you can have a charge on an invoice without a PI involved.

[cosmic scaffold]

I see. Yeah that's expected. So instead you should be able to call Invoice Payment with

  payment: {
    type: 'charge',
    payment_intent: '{CHARGE_ID}',
  },

[upper coyote]

That doesn't look possible, according to the api reference though. Only lets you look up payment_intent and payment_record? Or is the API reference wrong? See screenshot here

[cosmic scaffold]

Oops I see

Sorry

Do you have an example Charge Id? I want to see how it is linked to an Invoice in the first place

[upper coyote]

I do not: I'm still in the prototyping phase so I don't have any data

[cosmic scaffold]

This change here means for when you have an Invoice first and it generates the underlying Payment Intent, then the Charge, outlining how you can find the Invoice or the PaymentIntent from each other.

But if your CA starts from a pure Charge created via Charge API, I am not sure how they would create and link an Invoice here

[upper coyote]

Yeah, I'm not sure either. Was a lot more clear before the breaking change in Basil.

It also feels wrong to need to hit the API to connect PIs to invoices, instead of having pointers from the PI to the invoice payment. Feels like a ton of overhead for Stripe, because now I need to hit the service every time I get an event.

[cosmic scaffold]

yep I agree it's not great. It's a trade-off we decided to make