#rene_api

1 messages · Page 1 of 1 (latest)

chrome torrentBOT
#

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

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

sacred frigate
#

👋 happy to help

#

normally if you use the same parameters the invoice preview should generate the same amount_due as its counterpart

sleek oxide
#

Here's our exact flow:

  1. Call invoices/upcoming with subscription_items, proration_date, proration_behavior, billing_cycle_anchor, discounts → returns amount_due
  2. Create a standalone PaymentIntent with that exact amount_due. Customer pays via Klarna.
  3. On payment_intent.succeeded webhook, call subscriptions/update with the exact same parameters stored in PI metadata. This creates an invoice.
  4. Call attach_payment to link the PI to that invoice. It works most of the time, but occasionally the invoice from step 3 has amount_due 1 cent less than what invoices/upcoming returned in step 1. The attach_payment then fails with amount_too_large.

In the Stripe Dashboard under Transactions I can see the PaymentIntent with amount 1448.27 but the invoice shows 1448.26.

sacred frigate
#

the amount due is 1,488.26 whereas the PI is 1,488.27

sleek oxide
#

Yes, exactly. That's the issue. The PI was created with the amount from invoices/upcoming (1,488.27) but when we later called subscriptions/update with the same parameters, the invoice was created with 1,488.26. So
attach_payment fails because the PI amount is larger than the invoice amount. Why is there a 1 cent difference if the parameters are identical?

sacred frigate
#

would you mind sharing the request ID where you do the preview?

chrome torrentBOT
sleek oxide
#

Thanks for the suggestion!

#

Can you explain what causes the 1-cent discrepancy between invoices/upcoming and the actual invoice when all parameters are identical? Is this a known rounding issue with proration calculations?

void barn
#

👋 Hi there! I'm taking over for my colleague. Let me take a look

#

would you mind sharing the request ID where you do the preview?
Do you have an example of this, and the invoice update? Are they using the same proration timestamp, for example?

sleek oxide
#

We don't have the exact request ID for the preview call, but the parameters sent are identical — they come from the same UpgradeConfig object in our code. The preview call uses:
subscription: sub_1TKGXhHBmm4kY2j7md2czElJ
subscription_items: [{id: "si_UIsIxVMssK1AMm", price: "price_1PsQeAHBmm4kY2j7NoDlEBWG", quantity: 1}]
subscription_proration_date: 1775733332
subscription_proration_behavior: always_invoice
subscription_billing_cycle_anchor: unchanged
This returned amount_due: 148827.

Step 2 — PaymentIntent creation (request ID: req_lENkLDIjqUqvT7):
Created with amount: 148827 (the exact value from the preview).
proration_date in metadata: "proration_date": "1775733332",

Step 3 — Subscription update (on payment_intent.succeeded webhook):
{
"items": [{"id": "si_UIsIxVMssK1AMm", "price": "price_1PsQeAHBmm4kY2j7NoDlEBWG", "quantity": "1"}],
"proration_date": "1775733332",
"proration_behavior": "always_invoice",
"billing_cycle_anchor": "unchanged",
"collection_method": "send_invoice",
"days_until_due": "1"
}
This created an invoice with amount_due: 148826 (1 cent less).
So yes, the same proration_date timestamp (1775733332) is used in both the preview and the actual update. The only differences are:

  • Preview uses subscription_* prefixed params (as required by the upcoming endpoint)
  • Update adds collection_method: send_invoice and days_until_due: 1 (needed for the deferred payment flow)
    Could collection_method: send_invoice affect the proration calculation or rounding? That's the only parameter that differs between preview and update
void barn
#

You'd really need to provide request IDs in order for us to look at it more closely. The one ID you provided wasn't for a Payment Intent create.