feat(billing): Add charge service and capture charge endpoint#206
feat(billing): Add charge service and capture charge endpoint#206noahsmartin merged 9 commits intomainfrom
Conversation
Introduces a new charge service under billing/v1/services with a CaptureCharge endpoint. The request carries payment intent details and an optional invoice reference; the response reports whether the charge was paid and an optional failure code for downstream error handling. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
The latest Buf updates on your PR. Results from workflow ci / buf-checks (pull_request).
|
| bool perform = 1; | ||
| int64 amount = 2; | ||
| string description = 3; | ||
| string payment_intent = 4; |
There was a problem hiding this comment.
what is this? can it be an enum?
There was a problem hiding this comment.
it comes from stripe, so I don't think it can, will double check
There was a problem hiding this comment.
Decided to punt on this for now and just removed it. It's definitely not an enum, it's an ID provided by stripe when a payment needs to be retried due to some security verification. Figured that might warrant a separate charge service endpoint but no need to worry about it in phase 1
Replace the perform boolean with a ChargeMethod enum so callers can distinguish between recording a charge locally (NONE) and billing via Stripe (STRIPE). Rename amount to amount_cents to make the unit explicit, switch organization_id to uint64 to match other billing endpoints, and drop payment_intent from the request. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Allow callers to omit a human-readable description when capturing a charge, so internal or system-initiated charges are not forced to fabricate one. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Close the gap left by removing payment_intent so field numbers remain contiguous. Safe to renumber since the proto has not been released. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
| message CaptureChargeResponse { | ||
| bool paid = 1; | ||
| optional string failure_code = 2; | ||
| } |
There was a problem hiding this comment.
wouldn't you want to return the charge id here?
There was a problem hiding this comment.
I'm hoping it would not be necessary, there isn't any other API that allows you to provide a charge id so not sure why that would need to be exposed
Add CHARGE_METHOD_UNSPECIFIED as the zero value so unset charge_method fields are not silently treated as NONE, which could let Stripe-bound charges skip billing. Switch amount_cents to uint64 to match other monetary fields in the billing protos and prevent callers from accidentally passing negative debits. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit b40676f. Configure here.

Introduces a new charge service under billing/v1/services with a CaptureCharge endpoint. The request carries payment intent details and an optional invoice reference; the response reports whether the charge was paid and an optional failure code for downstream error handling.
Two other endpoints that will belong in charge service but we don't need yet for the first milestone are: