Accepting payments

One request shape for every method.

POST /v1/payments

Field	Type	Notes
`method`	string	Required. See payment methods.
`amount`	integer	Required. Minor units. €10.50 is `1050`.
`currency`	string	Required. ISO 4217, e.g. `EUR`.
`country`	string	Customer's country. Required by most local methods.
`success_url`	string	Required. HTTPS.
`error_url`	string	Required. HTTPS.
`reference`	string	Your order id. Searchable.
`customer`	object	`first_name`, `last_name`, `email`, `reference`.
`metadata`	object	Returned untouched on every read.

Amounts are integers in minor units. Sending 10.50 is rejected rather than interpreted. That is deliberate: silently reading it as ten and a half cents would undercharge by a factor of a hundred, and the error would surface in your bank statement rather than your logs.

Validation happens before the bank sees it

Scheme rules are enforced here, so you get a precise error instead of an opaque acquirer rejection.

{
  "error": {
    "type": "invalid_request_error",
    "code": "method_requirements_not_met",
    "message": "The request does not satisfy iDEAL's requirements.",
    "details": [
      { "code": "currency_not_supported", "field": "currency",
        "message": "iDEAL supports EUR, not GBP." },
      { "code": "country_not_supported", "field": "country",
        "message": "iDEAL is available to customers in NL, not GB." }
    ]
  }
}

Reading a payment

GET /v1/payments/{id}

GET /v1/payments

List accepts status, method, reference, limit and created_before for keyset pagination.

PreviousTesting NextPayment lifecycle