Payment connections are addressed by id
The {provider} path segment becomes {connection_id} on nine payment-connection paths. The old paths are gone, with no coexistence window.
A provider slug does not name a connection: one NIF can hold several connections with the same provider — one per external account within an environment — so the old path picked one of them ambiguously whenever there was more than one. The identifier names it without ambiguity, and GET /v1/companies/{company_id}/payment-connections returns it.
Eleven operations over nine paths move. There is no coexistence window: keeping the ambiguous form alive is keeping the bug.
What else changed
- The substitution is mechanical:
/payment-connections/{provider}/…becomes/payment-connections/{connection_id}/…. Take the id from the connections list and use it where you used the slug. - It applies to the whole subtree: the connection itself (
PATCH,DELETE), its events list and detail, and the event actionsretry,draft,resolve,discardandrestore. - Two of those operations were retired days later — see the payments cleanup for which and why.
Endpoints
- GET/v1/companies/{company_id}/payment-connectionsReturns the connection_id you now address
- PATCH|DELETE/v1/companies/{company_id}/payment-connections/{connection_id}Replaces the {provider} form
- GET/v1/companies/{company_id}/payment-connections/{connection_id}/eventsReplaces the {provider} form
Where to go next
An import row without an address is a bad row
A customer import row with an incomplete address is now reported as a bad row instead of being created with placeholder values.
Addresses can be missing, and accept more characters
`issuer.address` is optional and is no longer filled with invented values, and one character set governs every address field.