A valid request URL is required to generate request examples{
"state": "renews_disabled",
"paidThrough": "2023-11-07T05:31:56Z"
}{
"state": "pending_review",
"paidThrough": "2023-11-07T05:31:56Z"
}{
"error": {
"code": "backend_resolution_failed",
"message": "<string>",
"retryable": true
}
}{
"error": {
"code": "unauthorized",
"reason": "missing_credentials",
"hint": "<string>"
}
}{
"error": {
"code": "backend_resolution_failed",
"message": "<string>",
"retryable": true
}
}{
"error": {
"code": "not_found",
"message": "<string>"
}
}{
"error": {
"code": "backend_resolution_failed",
"message": "<string>",
"retryable": true
}
}{
"error": {
"code": "payload_too_large",
"message": "<string>"
}
}{
"error": {
"code": "rate_limited",
"message": "<string>"
}
}{
"error": {
"code": "backend_resolution_failed",
"message": "<string>",
"retryable": true
}
}Stop future Cloud phone renewal at Stripe's current period end
An org admin can disable a monthly Cloud phone’s next Stripe charge without returning the phone or refunding the current payment. The server verifies the exact account, Customer, subscription, Price, latest verified paid invoice and current billing period, then schedules cancel_at_period_end=true and reads it back. The action is safe to repeat. paidThrough is payment evidence, not a guarantee of uninterrupted supplier availability. Use /cancel or /return for their separate immediate refund/return meanings. With a draft or open renewal invoice, a durable operator alert is recorded before the stop, and a confirmed stop returns 202 because the existing invoice can still collect. An uncertain Stripe state answers 503; it never claims future retries were stopped without confirmation.
Hosted deployments only. A local checkout does not mount this route, so calling it there is a 404.
A valid request URL is required to generate request examples{
"state": "renews_disabled",
"paidThrough": "2023-11-07T05:31:56Z"
}{
"state": "pending_review",
"paidThrough": "2023-11-07T05:31:56Z"
}{
"error": {
"code": "backend_resolution_failed",
"message": "<string>",
"retryable": true
}
}{
"error": {
"code": "unauthorized",
"reason": "missing_credentials",
"hint": "<string>"
}
}{
"error": {
"code": "backend_resolution_failed",
"message": "<string>",
"retryable": true
}
}{
"error": {
"code": "not_found",
"message": "<string>"
}
}{
"error": {
"code": "backend_resolution_failed",
"message": "<string>",
"retryable": true
}
}{
"error": {
"code": "payload_too_large",
"message": "<string>"
}
}{
"error": {
"code": "rate_limited",
"message": "<string>"
}
}{
"error": {
"code": "backend_resolution_failed",
"message": "<string>",
"retryable": true
}
}Authorizations
The control surface credential. Send Authorization: Bearer <token>.
Two kinds of token are accepted and they are told apart by shape, not by a separate header. A token beginning pbk_ is an org scoped API key, whose public half and secret half are generated together and of which only a hash of the secret is ever stored; anything else is treated as an OAuth 2.1 access token and verified against the authorization server's keys.
Both resolve to the same context: an org, a principal and a set of scopes. Nothing downstream branches on which channel you used, with one deliberate exception, key management, which requires a signed-in person so that a key can never mint another key.
Scopes are enforced when MCP tools are REGISTERED rather than when they are called, so a tool your credential cannot use is absent from tools/list rather than refused mid gesture.
Path Parameters
The order id, as GET /v1/fulfilments reports it.
Response
Stripe confirmed the period-end stop.