Stripe Payments

Answers billing questions from Stripe — who this customer is, what they were charged, what they are subscribed to — without handing an agent a key that can move money.

What you get

• stripe.customer.get — one customer record by id.
• stripe.charges.list — recent charges, optionally for one customer.
• stripe.subscriptions.list — subscriptions by customer and status.

All three are read-only, and the key they use is meant to be read-only too.

What you need

• Stripe restricted key — created under Developers → API keys → Restricted keys, with read access to Customers, Charges and Subscriptions. A secret key would give these bindings the ability to refund and to charge; a restricted key cannot, whatever an agent asks for.
• JWKS endpoint — the host where your identity provider publishes its signing keys, without a scheme.
• Token audience — the aud claim your callers' tokens carry.
• Stripe API version — optional; already pinned to the version these bindings were written against.

How it works

The interesting decision here is not in the config, it is in the key. Stripe enforces scope server-side, so a restricted key makes "read-only" a property of the credential rather than a property of which bindings happen to exist. Adding a write tool later would then fail loudly at Stripe rather than quietly succeed.

Audit is on and fail_closed. Every gated call is written to a hash-chained log, and the gateway refuses to serve if the sink is not accepting writes — which is the posture you want when the tool answers questions about money.

Stripe-Version is pinned per request, so response shapes do not change under you.

Notes

Stripe's list endpoints paginate with cursors rather than page numbers. These bindings expose limit only; add starting_after to the schema and the query if a caller needs to walk a long history.

The test and live keys have different prefixes and different data. A template filled with rk_test_… answers questions about your test mode, which is usually the right place to start.