#oranges13_api

1 messages · Page 1 of 1 (latest)

grim prawnBOT
mossy stagBOT
#

Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.

grim prawnBOT
#

👋 Welcome to your new thread!

⏲️ We'll be here soon! We typically respond in a few minutes, but in some cases we might need a bit more time (e.g., server's busy, you've got a complex question, etc.).

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

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

leaden sage
#

👋 hey there! the tl;dr is we receive a webhook invoice.payment_suceceded and my initial thought was that subsequent retrievals of the invoice would keep the same billing_reason but it seems to change between requests. Any idea?

#

Here's another one, in_1PT274Lv5IzfagowLxYusRPl and the initial event was evt_1PT275Lv5IzfagowXC9uMwHP

#

also event evt_1PT275Lv5IzfagowHuIVYtgd says billing_reason: subscription_create but other requests say subscription_update

severe kite
#

Hey there, I would expect the billing_reason to reamin unchanged, too. Can you share the result of retrieving in_1PSyPSLv5IzfagowpS67vOLz? I cannot see the GET response body

leaden sage
#

yes!

#

initial webhook ```
{
"object": {
"id": "in_1PSyPSLv5IzfagowpS67vOLz",
"object": "invoice",
"account_country": "US",
"account_name": "...",
"account_tax_ids": null,
"amount_due": 10346,
"amount_paid": 10346,
"amount_remaining": 0,
"amount_shipping": 0,
"application": null,
"application_fee_amount": null,
"attempt_count": 1,
"attempted": true,
"auto_advance": false,
"automatic_tax": {
"enabled": false,
"liability": null,
"status": null
},
"billing_reason": "subscription_create",
"charge": "ch_3PSyPTLv5Izfagow1hwI8XvK",
"collection_method": "charge_automatically",

#

GET https://api.stripe.com/v1/invoices/in_1PSyPSLv5IzfagowpS67vOLz
2024-06-18 5:33:06 AM EDT

  "params": [],
  "response": {
    "id": "in_1PSyPSLv5IzfagowpS67vOLz",
    "object": "invoice",
    "account_country": "US",
    "account_name": "...",
    "account_tax_ids": null,
    "amount_due": 10346,
    "amount_paid": 10346,
    "amount_remaining": 0,
    "amount_shipping": 0,
    "application": null,
    "application_fee": null,
    "attempt_count": 1,
    "attempted": true,
    "auto_advance": false,
    "automatic_tax": {
      "enabled": false,
      "liability": null,
      "status": null
    },
    "billing": "charge_automatically",
    "billing_reason": "subscription_update",
    "charge": "ch_3PSyPTLv5Izfagow1hwI8XvK",
    "closed": true,
    "collection_method": "charge_automatically",
#

as far as I can tell we didn't update the invoice until after the request but the timestamps are all at the same instant in some cases.

severe kite
#

Hey ther,e taking a look at this some more

leaden sage
#

no worries, thank you!

#

We are unfortunately using a really outdated version of the api. If that's the issue, I can try bumping that on some of these requests.

severe kite
#

Ok, right

mossy stagBOT
severe kite
#

this is due to your using an old (2017) api version

#

The billing_reason attribute of the invoice object now can take the value of subscription_create, indicating that it is the first invoice of a subscription. For older API versions, billing_reason=subscription_create is represented as subscription_update.

#

Your webhook endpoint has no explicit API version so uses your account default of 2020-03-02 (after that change) while your retrievals are using 2017-04-06 (before that change) explicitly.

#

Thus, they are different

leaden sage
#

AHAAAA

severe kite
#

The underlying object is not changing, if you retrieve the invoice with a newer api version (say 2020-03-02) then they will match

leaden sage
#

🙏 thank you. I can fix this.

#

OK, one more question -- do you know when the sources api was official deprecated in the api? Because we are still (sadly) using that, moving off it soon but not yet. If psosible I would like to get our system as far ahead as we can in one go

severe kite
#

Note that the deprecation is currently applicable only to non-card payment methods. Card will still be supported, though we encourage you to migrate to newer APIs.

leaden sage
#

awesome, thank you. Yes. We are attempting to support wallets in other initiatives and our outdatedness is causing major issues. We're probably going for a full rewrite 🙂