Quick Summary
This release spans 100 API changes across the Stripe OpenAPI spec — 36 classified as breaking and 64 as additive features — touching over 50 resources ranging from /v1/accounts and billing alerts to the full Terminal reader surface. The dominant theme is the introduction of two new device_type enum values, stripe_s710 and simulated_stripe_s710, propagated across every Terminal reader endpoint. Because these new enum values appear in response payloads, any client code that exhaustively validates or switches on device_type without a default/fallback branch may fail at runtime when it encounters an unrecognized value.
Editor's Note: We consider this a meaningful hardware-expansion release rather than routine maintenance — the stripe_s710 device type signals a new physical reader entering the Stripe Terminal ecosystem, and its simulated counterpart suggests test-environment parity is shipping alongside it. We've been tracking Stripe's pattern of pairing real hardware additions with sandbox equivalents, and this follows that convention closely. If your integration uses a switch or exhaustive match on device_type, adding a catch-all case before you upgrade is the single most important thing you can do right now.
---
Changes by Severity
#### 🔴 Immediate Action Required
New device_type enum values across all Terminal reader endpoints
The device_type field in Terminal reader responses now includes two additional enum values: stripe_s710 and simulated_stripe_s710. These values appear in the response schema for every Terminal reader action endpoint, including:
GET /v1/terminal/readers — affects data/items/device_type in list responsesGET /v1/terminal/readers/{reader} — affects device_type in both TerminalReaderReader and TerminalReaderDeletedReader subschemas within the anyOf unionPOST /v1/terminal/readers/{reader}/cancel_actionPOST /v1/terminal/readers/{reader}/collect_inputsPOST /v1/terminal/readers/{reader}/collect_payment_methodPOST /v1/terminal/readers/{reader}/confirm_payment_intentPOST /v1/terminal/readers/{reader}/process_payment_intentPOST /v1/terminal/readers/{reader}/process_setup_intentPOST /v1/terminal/readers/{reader}/refund_paymentPOST /v1/terminal/readers/{reader}/set_reader_displayPOST /v1/test_helpers/terminal/readers/{reader}/present_payment_methodPOST /v1/test_helpers/terminal/readers/{reader}/succeed_input_collectionPOST /v1/test_helpers/terminal/readers/{reader}/timeout_input_collectionWhy this is breaking: Stripe classifies new enum values as breaking changes because strictly typed clients — generated SDKs, TypeScript discriminated unions, Rust enums, Go iota constants, or any language construct that treats an unrecognized enum value as an error — will fail to deserialize responses containing stripe_s710 or simulated_stripe_s710. The anyOf union in /v1/terminal/readers/{reader} compounds this: both the live reader subschema (TerminalReaderReader) and the deleted reader subschema (TerminalReaderDeletedReader) carry the new values, so even code paths that handle deleted readers are affected.
---
#### 🟡 Plan Ahead
Expanded account, billing, and balance resource surface
The diff includes 64 additive feature changes across resources including /v1/account, /v1/account_sessions, /v1/billing/alerts, /v1/balance_settings, /v1/apps/secrets, and the full /v1/accounts/{account} family (bank accounts, capabilities, external accounts, people, persons, login links, reject). While additive changes are non-breaking by default, they may introduce new optional request fields or response properties that your integration should account for over time — particularly if you cache or snapshot response shapes, generate types from the spec, or use strict schema validation on inbound webhook payloads.
The /v1/billing/alerts family (activate, archive) and /v1/balance_settings are relatively newer surfaces; if your team is building on these, reviewing the expanded schemas before your next feature sprint is worthwhile.
---
#### 🟢 Informational
Test helper endpoints updated for stripe_s710 simulation
Three test helper endpoints under /v1/test_helpers/terminal/readers/{reader}/ — present_payment_method, succeed_input_collection, and timeout_input_collection — now reflect the simulated_stripe_s710 device type in their response schemas. This means sandbox testing for the new hardware model is available immediately, which is useful for teams who want to validate their enum-handling logic before encountering a physical stripe_s710 in production.
---
Migration Playbook
1. Audit all device_type switch/match statements. Search your codebase for any exhaustive handling of the device_type field from Terminal reader responses. Common patterns include TypeScript switch blocks with no default, Rust match arms without a wildcard, and Python code using assert device_type in KNOWN_TYPES.
```typescript
// Before — will throw or produce undefined behavior on new values
switch (reader.device_type) {
case "bbpos_wisepos_e": return handleWisePosE(reader);
case "stripe_m2": return handleM2(reader);
// No default — unsafe
}
// After — safe with fallback
switch (reader.device_type) {
case "bbpos_wisepos_e": return handleWisePosE(reader);
case "stripe_m2": return handleM2(reader);
case "stripe_s710": return handleS710(reader);
case "simulated_stripe_s710": return handleS710(reader); // treat as same path
default:
console.warn(Unrecognized device_type: ${reader.device_type});
return handleUnknownReader(reader);
}
```
2. Regenerate any auto-generated SDK or type definitions. If your project generates types from the Stripe OpenAPI spec (e.g., via openapi-typescript, openapi-generator, or a custom codegen pipeline), regenerate against the new spec at commit da3eadb239b4. Verify that device_type union types now include "stripe_s710" and "simulated_stripe_s710".
```bash
# Example using openapi-typescript
npx openapi-typescript https://raw.githubusercontent.com/stripe/openapi/da3eadb239b4/openapi/spec3.json \
--output src/types/stripe.d.ts
```
3. Update strict JSON schema validators. If you validate Terminal reader response payloads against a local JSON Schema copy (common in integration test suites), add the two new enum values to the device_type field definition:
```json
{
"device_type": {
"type": "string",
"enum": [
"bbpos_chipper2x",
"bbpos_wisepad3",
"bbpos_wisepos_e",
"mobile_phone_reader",
"simulated_bbpos_chipper2x",
"simulated_bbpos_wisepad3",
"simulated_bbpos_wisepos_e",
"simulated_stripe_m2",
"simulated_stripe_s700",
"simulated_stripe_s710",
"stripe_m2",
"stripe_s700",
"stripe_s710",
"verifone_P400"
]
}
}
```
4. Test against the simulated device in sandbox. Use the simulated_stripe_s710 value via the test helper endpoints to confirm your integration handles the new device type gracefully end-to-end before any physical hardware reaches your environment.
```bash
# Present a payment method on a simulated s710 reader
curl -X POST https://api.stripe.com/v1/test_helpers/terminal/readers/{reader}/present_payment_method \
-u sk_test_...: \
-d "type=card_present"
```
Confirm that the device_type field in the response reads simulated_stripe_s710 and that your application handles it without errors.
5. Review the anyOf union handling for /v1/terminal/readers/{reader}. This endpoint returns either a TerminalReaderReader or a TerminalReaderDeletedReader object. Both subschemas now carry the new enum values. If your code discriminates between these two subschemas before reading device_type, verify that both branches handle the new values — not just the live reader path.
6. Assess impact on the expanded account and billing resources. Review the 64 additive changes against your usage of /v1/account_sessions, /v1/billing/alerts, /v1/balance_settings, and the /v1/accounts/{account} sub-resources. If your integration caches response objects or generates strict types from these schemas, schedule a type-refresh cycle to incorporate any new optional fields.
7. Update internal documentation and runbooks. If your team maintains a list of supported Terminal hardware or a device-type routing table (e.g., for receipt formatting, UI layout, or capability gating), add stripe_s710 and simulated_stripe_s710 to those references now, even if the physical hardware hasn't arrived in your deployment yet.
---
Verification Checklist
switch, match, or exhaustive conditional blocks on device_type include a default or wildcard branch that handles unknown values gracefullyda3eadb239b4 and include "stripe_s710" and "simulated_stripe_s710" in the device_type unionsimulated_stripe_s710 device type using the /v1/test_helpers/terminal/readers/{reader}/present_payment_method endpointTerminalReaderReader and TerminalReaderDeletedReader code paths in your /v1/terminal/readers/{reader} response handling have been verified to accept the new enum valuesstripe_s710/v1/account_sessions, /v1/billing/alerts, and /v1/balance_settings have been reviewed for new optional fields that may affect cached response shapes or strict type definitionsstripe_s710 as an unexpected value---