Capture Payment
Test this endpoint live
Open the same request directly in API Explorer.
Server URL
Capture a payment by finalizing a previously authorized transaction and moving the funds from the customer’s card to your account. When a payment is first authorized, the customer’s bank sets aside the money but doesn’t transfer it yet. Capturing the payment completes the process and transfers those funds to you. *We recommend a minimum timeout of 60 seconds.* :::info Operations are processed synchronously All operations such as `CAPTURE`, `VOID` and `REFUND` are processed synchronously and the outcome is returned directly in the response, meaning webhooks are not required. We **strongly** recommend using the **Idempotency-Key** header, to ensure safe retries in case of network failure. :::
Authorization
BearerAuth In: header
Path Parameters
The id of the transaction to capture.
Header Parameters
Ensures that a request can be safely retried without causing duplicate operations. Typically used for actions like payment creation and operations such as refund and void to prevent accidental double processing. - If a response is replayed due to using the same key, the response will include the header `Idempotent-Replayed: true`. - Idempotency keys are scoped by **[Key, Endpoint, HTTP Verb]**; the same key on a different endpoint or method will not replay the original response. - Responses are cached for **24 hours**. After that, the cache is cleared, so idempotency is only guaranteed within 24 hours of the initial request.
Request Body
application/json
Capture request payload.
TypeScript Definitions
Use the request body type in TypeScript.
The amount to capture in minor units (e.g., 1095 = 10.95 DKK). You cannot capture more than authorized.
1 <= valueIf true, any remaining authorization balance will be voided after a successful capture. If the capture fails, nothing will be voided.
falseResponse Body
application/json
application/json
application/json
application/json
Physical Sale
Starts an in-person sale on a physical payment terminal connected to a Softpay point of sale. Physical transactions are processed using operation type SALE, which functions as an instant capture making sales function as both an AUTHORIZATION and CAPTURE in a single atomic operation. These transactions therefor cannot be voided. This endpoint creates the transaction immediately. The transaction returned in the response confirms that the sale request was accepted and created, but not that the cardholder has completed the payment yet. If terminal.id is provided, ePay targets that specific terminal. If terminal is omitted, ePay automatically routes the sale to the fallback terminal for the given point of sale. The pointOfSaleId must refer to a physical Softpay point of sale that belongs to your account. ### Refunds Physical transactions does not support card-not-present online refunds. Meaing the refund operation is not supported for physical transactions. To refund a previous purchase a PAYOUT transaction must be initiated instead by setting "type": "PAYOUT", which will initiate a transaction on the terminal sending funds to the card placed on the terminal. ### Notification You’ll receive the outcome of the payment on the notificationUrl you provide within the request, making it the primary way to track the result of this payment. Webhooks can be used separately if you need broader, system-wide updates. Early rejections, such as the SoftPay terminal being wrongly configured or blocked by another transaction will return a transaction response with state FAILED. If the transaction fails due to early rejections, the final state is returned in the response and no notification is sent to the notificationUrl.
Refund Payment
Refund a payment by returning money to the customer after it has already been captured. You can refund the full amount or only part of it (partial refund), depending on how much you want to return. The endpoint typically only returns a single refund operation. But if multiple partial captures have been requested, the endpoint might return multiple refund operations as each capture is refunded in isolation. All operations are returned in the same response. If you do not use partial captures, then you will only ever receive a single refund operation. We recommend a minimum timeout of 60 seconds. Operations are processed synchronously All operations such as CAPTURE, VOID and REFUND are processed synchronously and the outcome is returned directly in the response, meaning webhooks are not required. We strongly recommend using the Idempotency-Key header, to ensure safe retries in case of network failure.