#corethings - Metered Billing

1 messages · Page 1 of 1 (latest)

radiant moss
#

Hi 👋

#

So you've got a usage record that is in accurate for a specific customer & billing period?

royal salmon
#

correct

radiant moss
#

Doing some digging on this because it's not readily obvious

#

Which you probably already figured out 😁

royal salmon
#

🙂 yep - no worries.

radiant moss
#

Quick question, what is the action parameter you are using?

royal salmon
#

I've tried both set and increment but they don't solve my problem. I was hoping set was it but I think that's if there are multiple usage records on the same timestamp, it will either set to that value for that timestamp or add them together (with the increment) I was hoping that set would set the overall usage amount but it doesn't

radiant moss
#

Well I'm going to quote our resident billing expert's info on this as I can hardly improve on her words:

Once a Usage Record has been created, there is no way to delete it. However, a user can overwrite/correct an existing Usage Record by creating a new one with the same timestamp, the desired quantity, and action:set.

To correct Usage Records that were originally created with action:set, users can reset the quantity reported for that timestamp by setting quantity:0 like in the curl request below:

curl https://api.stripe.com/v1/subscription_items/si_xxx/usage_records
-u sk_test_xxx:
-d quantity=0
-d timestamp={{TIMESTAMP}}
-d action=set

To correct Usage Records that were originally created with action:increment, users cannot just set quantity:0 since a single timestamp could be tied to multiple Usage Records that were added together. Instead, they need to retrieve the current total usage reported for that timestamp, subtract the quantity they want to delete, and use that value as the quantity in their creation request.

curl https://api.stripe.com/v1/subscription_items/si_xxx/usage_records
-u sk_test_xxx:
-d quantity={{TOTAL_USAGE - QUANTITY_TO_DELETE}}
-d timestamp={{TIMESTAMP}}
-d action=set

These methods will only work if the Subscription tied to the Usage Record does not have any billing thresholds. Usage Records for those Subscriptions can only be created with action:increment.

royal salmon
#

...digesting

radiant moss
#

Would you be able to set quantity to 0 and then try to revise after that?

royal salmon
#

does it need to be at the exact timestamp that the intitial usage record was created? (I think I maybe misunderstanding timestamps in this case as timestamps are accurate to milliseconds right?)

radiant moss
#

I suspect you would need the exact same integer value.

royal salmon
#

Can I return all usage records with their associated timestamps for a given period?

radiant moss
#

Yeah I was just thinking that would be useful

#

I'm not sure if the period.start or period.end would be the value you are looking for.

#

Especially since the default is "now" whenever a usage record is created.

royal salmon
#

I tried that but it looks like it just groups everything together - in the below case, I need to see each of the 27 usage record timestamps if I was to override their values

  "object": "list",
  "data": [
    {
      "id": "sis_1KOAoKB7O0Hwjxxxxxxxxxxx",
      "object": "usage_record_summary",
      "invoice": null,
      "livemode": true,
      "period": {
        "end": null,
        "start": null
      },
      "subscription_item": "si_KvZTA9rVxxxxxx",
      "total_usage": 27
    }
  ],
  "has_more": false,
  "url": "/v1/subscription_items/si_KvZTA9rxxxxxx/usage_record_summaries"
}```
#

so, the 27 is currently the running total for the usage records ... so the time period works. It's just I can't seem to get to the individual usage records themselves to override them

radiant moss
#

Right. That does appear to be a significant limitation here.

royal salmon
#

Pretty early in the morning here my time so need to call it a night - don't think we're going to solve it tonight. Thanks for your help anyhow - if you do think of a fix, not sure you can update this thread but I'll keep an eye out. Thanks anyhow!

radiant moss
#

Will do! Just going to call out that the fix mentioned in the quoted text above for action: increment operates on the total so you might be able to use that approach (negative quantity to reduce usage).

royal salmon
#

tks. Yeah - it's a gap to be honest. Especially with incremental/metered type usage, I know my system may in some cases request too many/few usage records and I'll need to be able to rectify with those customers mid billing cycle. Otherwise, it's going to be a nightmare trying to issue refunds etc. The ability to set the overall number by either incrementing the total by X (or -X) to get the value back in line.... Thanks again for your help on this