Added Support for New Usage Based Billing #1727
Conversation
# Conflicts: # tests/Feature/UsageBasedBillingTest.php
|
|
||
| $startTime = $options['start_time'] ?? 1; | ||
|
|
||
| $endTime = $options['end_time'] ?? time(); |
There was a problem hiding this comment.
Would these almost always be passed? If so, should we just make them arguments?
There was a problem hiding this comment.
Hi Taylor, I think so, it's required as shown here https://docs.stripe.com/api/usage-record-summary/object
So yes, I think they would be better suited as arguments to the function
| * @param array $requestOptions | ||
| * @return \Illuminate\Support\Collection | ||
| */ | ||
| public function meterEventSummaries(string $meterId, array $options = [], array $requestOptions = []): Collection |
There was a problem hiding this comment.
The reportMeterEvent uses $meter - this uses $meterId? Should they also both support Backed Enums?
There was a problem hiding this comment.
So, the $meter is the event name (the meter has to be configured to listen to a specific event name), but for the summaries endpoint, we need the meter ID that's created with the meter, different from the event_name. It could be a backed enum, but I envision someone using them by saving the value for their event names and meter IDs in config files or a DB if they are created dynamically.
They could be Enums, we could also have a data class that houses both the ID and the Event Name.
| * @param array $requestOptions | ||
| * @return \Illuminate\Support\Collection | ||
| */ | ||
| public function meters(array $options = [], array $requestOptions = []): Collection |
There was a problem hiding this comment.
If we end up supporting Enums for meter names / IDs below, should we also support them here?
There was a problem hiding this comment.
I think yes, if we end up passing meters around as an enum or a class, we should return them as such inside the collection.
This PR adds support for the new stripe usage billing based on billing meters