2 min read
Endpoint
| Method | GET |
| Path | /partner/v1/payments/{id} |
| Ring | partner (OAuth) |
| Auth | OAuth |
Request
Path parameter id. Requires payments:read.
Response
A JSON payment object with its current status — provisioned, pending, settled or failed — plus amounts and references. For push updates rather than polling, subscribe to the payment webhook, which fires on settlement.
Errors & notes
A 404 for an unknown payment; a 403 without payments:read. Treat settlement as authoritative from the webhook or this read, not from provisioning success.
Reconciling settlement
Settlement is the state that matters most here, and it is authoritative from either the settlement webhook or this read — never from the success of provisioning, which only creates the collection. Build your flow so a payment is treated as settled only when this endpoint (or the webhook) says so. Remember too that collecting a payment in is separate from money-out, the platform's one governed manual gate; the two are distinct events in your data model.
Frequently asked questions
When is a payment actually settled?
When its status reads settled here or a settlement webhook fires — not when the link is provisioned. Provisioning only creates the collection; settlement is a later, separate event.
Should I poll for settlement?
Prefer the settlement webhook. Use this read to reconcile after a missed event or for a support lookup, backing off between polls to respect the bucket.
Can I treat provisioning success as settlement?
No. Provisioning only creates the payment collection. Settlement is a later, separate event — confirm it from this read or the settlement webhook before you treat the money as received.
Funding for UK limited companies
Credicorp lends to your company, not to you personally — short-term working capital with no personal guarantee. See what your business could access.