jairo094215_api

[tired swan]

👋 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/1436320589714554990

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

[gray mesa]

Hi,
Has there been any recent change in how invoices created with the out_of_band flag behave? Until recently, these invoices only reflected a single payment, but now we’re seeing two — one of them labeled “Out of band payment for invoice XXX”, which didn’t appear before.
Previously, this setup didn’t trigger any charge to the customer — we used it to record invoices in Stripe for payments processed through other channels. However, with this new behavior, the customer is now being charged by Stripe as well, resulting in duplicate charges (one external and one via Stripe). In addition, the new Stripe charge cannot be refunded.
Could you please confirm if this behavior has changed recently or if this might be an unintended issue?
Thanks!

[glad rover]

👋 Hi there!

Do you have an example invoice ID that you can share?

[gray mesa]

For example:

• Invoice in_1SFzzQDyCiiQ0txVoPZhHDsO was created with the out_of_band flag and, as expected, has no related payment.
• Invoice in_1SQ3FdDyCiiQ0txVCGBvE6WH, created in exactly the same way, did generate a related payment, which is the behavior we want to avoid.

[glad rover]

Thanks for those. I don't see any charges related to either invoice though

I see that a Payment Record is being generated for the second invoice, which is a new API: https://docs.stripe.com/changelog/clover/2025-10-29/payment-records

[gray mesa]

I can see that the second one has a related Payment

And yes, if I open this payment I can see that this is a payment record (pr_65TZRD1tqvWioMui2l841DyCiiQ0txVKxE)

I don't know what's this new kind of object

[glad rover]

Right, that will be the new Payment Record. You can see that it was paid outside of Stripe

Let me check whether this should be appearing

[glad rover]

But overall it's just adding more information about how the invoice was paid

[clear gorge]

👋 taking over for my colleague. Let me know if there's any follow-up Qs I can answer!

[gray mesa]

Before these payment records started being generated, the customer did not receive any charges from Stripe.

How can we avoid this charge from Stripe?

Customers are asking for refunds and we can't even issue them

[clear gorge]

I'm catching up on the thread, please give me a moment and I'll be with you

[gray mesa]

Ok, thanks 🙏

[clear gorge]

when you say

Customers are asking for refunds

do you mean that they were charged twice?

I can't see 2 payments on the invoice you shared

the objects have changed in our latest API version https://docs.stripe.com/changelog/clover/2025-10-29/invoicing-payment-records and now we introduced payment records for invoices.

[gray mesa]

Yes, customers are being charged twice, once by Stripe and also through out external payment method, which is the primary method for collecting these invoices and the only one until you made this change. We collect these invoices through other payment methods, but then we need to record the payment in our billing system. To do this, we created invoices with out_of_band=true so that Stripe wouldn't process the payment and would simply create the invoice. But the problem is that after this change Stripe is also processing the payment.

[clear gorge]

that's weird. how did you make sure that they were billed twice?

[gray mesa]

Let me share some screenshots with you

[clear gorge]

if you're seeing "Payments" in the dashboard that's expected

if the user is seeing two payments on their bank account for example then this might be problematic then

[gray mesa]

This is a screenshot that shows the old behavior. The invoice in question was created as out_of_band=true and as you can see, it only generated a payment at the Stripe level, and this did not involve any charge to the customer's bank account.

Now, recent invoices created in the same way generate two payments, and from this point on, customers are complaining that they have been charged twice for the product. Therefore, we believe that Stripe is making an additional charge on top of the original charge we made to the customer through external payment methods.

Above all, I want to emphasize that the problem isn't that Stripe is charging twice, but that we don't want Stripe to charge these invoices at all because they only reflect amounts already collected externally, and this was the previous behavior.

Am I explaining myself correctly?

[clear gorge]

I'm taking a look

would you mind sharing the customer ID of Andrei?

[gray mesa]

yes

cus_TMHAyFwZ18TiLO

[clear gorge]

but these are not related payments

one happened from a Checkout Session

and one is from the invoice

[gray mesa]

Hmmm, I don't understand

I think we didn't change anything from our side

We continue creating this kind of Invoices by the same way, and before this the customer's didn't receive any charge from Stripe

I stand corrected, they did receive a charge, but it's for the checkout session, which is the external payment method I referred to earlier, but which I didn't think it necessary to mention because I wanted to differentiate it from payments created through Billing.

[normal bear]

Hello there, something is clearly not working as expected and we're going to need to take some time to investigate further. Do you mind writing in to our team so we can take this investigation async and loop in relevant teams?

https://support.stripe.com/contact/email?topic=api_integration

[gray mesa]

@clear gorge mentioned that there are clearly two charges, one from the checkout session and another from the invoice. Can we find out why that invoice generated a charge if the invoice was created as 'out_of_band=true'?

In other words, after the recent changes to your API, is using out_of_band still the correct way to create an invoice that doesn't generate any charges?

And relating this to the new Payment Records, why does this action generate one of these new elements? And could these new elements be the cause of this unexpected invoice payment?

[normal bear]

Having looked at these examples in the screenshot though, the 2 payments are representative of separate payments. Not a duplicate payment for the invoice:

• The top line ('Out of band...') is the payment record for the invoice (in_1SQ3FdDyCiiQ0txVCGBvE6WH) paid out-of-band here
• The bottom line (pi_xxx) is for a separate Checkout Session created by your integration

I think the confusion stems from the appearance of the 'Out of band' line, which is new. But there is no actual 2nd payment here. That is just a record of the out of band payment

[normal bear]

There's no actual payment, it's just a record of the out-of-band payment that happened off Stripe: https://docs.stripe.com/payments/payment-records

PaymentRecords enable interoperability across Stripe products. Products such as Subscriptions (with smart retries) and Invoices paid out of band use PaymentRecords as the core primitive for tracking payment outcomes.

[normal bear]

There's no actual charge, API object or otherwise, for the out of band payment. Your customer was not charged multiple times

Does that help clear up the confusion?

[gray mesa]

Okay, we'll review the cases further and request more evidence from the clients. We'll contact you again if we have any further questions. Thank you very much!