put
https://test-api.payology.io/api/v1/payment/
Update an X9 payment. A normal void uses payment_status=Voided; a processed payment cannot be voided through this operation. At least one of tracking_number, payment_status, receipt_email or receipt_phone is required. Rating-only updates fail the current required-field middleware.
Request examples
Void
PUT /api/v1/payment/77777777-7777-4777-8777-777777777777?type=X9 HTTP/1.1
Authorization: <PAYOLOGY_API_KEY>
Accept: application/json
Content-Type: application/jsonReceipt
PUT /api/v1/payment/77777777-7777-4777-8777-777777777777?type=X9 HTTP/1.1
Authorization: <PAYOLOGY_API_KEY>
Accept: application/json
Content-Type: application/jsonResult codes in the response examples
HTTP status and result code are operation-specific. Field-validation messages can include the affected field name.
| HTTP | Code | Result | Meaning |
|---|---|---|---|
| 200 | R0000 | Ok | The request was processed successfully |
| 400 | R0002 | Error | Field is not properly formatted |
| 400 | R0162 | Error | Tracking number cannot be updated for payments that do not have an associated shipping contact |
| 400 | R0163 | Error | Only payments in pending status can be voided |
| 401 | R0003 | Error | Authentication token is invalid |
| 403 | R0003 | Error | Access not allowed |
| 404 | R0161 | Error | Payment token is invalid |
| 500 | R0999 | Error | Something went wrong |
Recent Requests
Log in to see full request history
| Time | Status | User Agent | |
|---|---|---|---|
Retrieving recent requests… | |||
Loading…
defaultOther infrastructure or forwarded downstream response. HTTP status and body must be preserved; do not assume every error has a Payology R-code. No fixed payload is guaranteed.