Authorize API
POST/rest/authorize
/rest/authorizeAuthorize API is used to create payment authorizations without immediately capturing funds. This is useful for scenarios where the final amount may change (such as hotels, car rentals, or restaurants with tips) or when you want to verify card validity before shipping goods. Authorized payments must be captured later using the Capture API or reversed if the transaction is cancelled.
Authorize API Parameters
Authorization API parameters share the same parameter blocks as the Payment API, depending on your payment method:
- Common Parameters - Required for all payment methods
- Billing Address Parameters - Required for most payment methods
- Redirection URL Parameters - Required for redirect-based payment methods
- Cardholder Data Parameters - Optional for server-to-server card processing (requires PCI DSS compliance)
Please refer to the Payment API documentation for the shared parameter blocks.
Authorization-only parameters are documented per payment method. They are not accepted on /rest/payment.
In case of re-authorizations, shipping and billing addresses can be skipped. You can pass the transaction ID of the previously authorized transaction as original_transaction_id and the new amount which must be higher than the previously authorized amount. The authorized amount on the transaction will be updated to the new amount upon successful re-authorization. For reducing the authorized amount, please use the Reversal API instead.
Both the Payment API and Authorization API accept an amount of 0 for Card, Apple Pay, and Google Pay payment methods in both regular and recurring mode. This is used for account status checks — verifying that the card is valid and active without actually charging or blocking any funds. The transaction will be processed as an account verification.
Zero-amount transactions can also be used to simulate a "save card" feature. Create a zero-amount recurring transaction with recurring=1 and amount=0. The returned transaction_id can then be referenced as original_transaction_id in a future payment request to charge the saved card.
Like the Payment API, Authorization API may return a client_action in some cases. When authorizing card payments, the end user has to input the card number — so the API returns a redirection action with a URL. When authorizing a recurring card payment that refers to a previous successful authorization, the transaction returns a successful response without redirection. The parameters for card authorization are identical to those of the payment request.
Card POS-Specific Parameters (Optional)
When authorizing POS (card-present) transactions using payment_type: "cardpos", additional parameters are required:
| Parameter | Type | Comments |
|---|---|---|
pos_data required | Object | Required only for POS payment type. POS-specific data including card, terminal information, and transaction type |
The pos_data object includes:
- type - Terminal entry mode information
- card - Card data (number, expiry, track2_data, emv_data)
- terminal - Terminal information (type, id, attended, capabilities)
- pin_block - PIN block data (optional, when online PIN verification is required)
For the full field list and types, see the POS Parameters block in the Payment API. Refer to POS Payment Method for end-to-end examples.
Wero-Specific Parameters (Optional)
When authorizing Wero transactions using payment_type: "wero", the following authorization-only parameter is available:
| Parameter | Type | Comments |
|---|---|---|
wero_capture_event Optional | String | The event that triggers the capture of the payment. One of the following: SHIPPING, DELIVERY, AVAILABILITY, SERVICE_FULFILMENT, OTHER. When missing, falls back to OTHER. This information is displayed to the end user when making the payment. |
Refer to Wero for payment method details. Example authorization request:
payment_typeStringrequiredweroorder_idStringrequiredamountFloatrequiredcurrencyStringrequiredmerchant_referenceStringrequiredadditional_transaction_dataStringpostback_url as part of the postback data.postback_urlStringrequiredsuccess_urlStringrequirederror_urlStringrequiredwero_checkout_urlStringrequiredwero_capture_eventStringSHIPPING, DELIVERY, AVAILABILITY, SERVICE_FULFILMENT, OTHER. When missing, falls back to OTHER. This information is displayed to the end user when making the payment.POST /rest/authorize
Authorization: Basic <base64(api_key:api_password)>
Content-Type: application/json
{
"payment_type": "wero",
"order_id": "12345678",
"amount": "15.90",
"currency": "EUR",
"merchant_reference": "12345678 - Test Shop",
"additional_transaction_data": "customer_id=123ABC, billing_info=12345678",
"postback_url": "https://your-postback.url.com",
"success_url": "https://your-success.url.com",
"error_url": "https://your-error.url.com",
"wero_checkout_url": "https://your-shop.url.com/checkout",
"wero_capture_event": "SHIPPING"
}
Authorize API Response
The response is identical to the Payment API response.
After successful authorization, you must either capture the funds or reverse the authorization. Authorizations may expire after a certain period (typically 7-30 days depending on the card network and issuer).
Re-Authorization
Re-authorizations allow you to increase the authorized amount on an existing transaction. This is useful for scenarios where the final charge exceeds the original authorization.
To perform a re-authorization, send a second request to POST /rest/authorize passing the transaction_id of the previously authorized transaction as original_transaction_id, along with the new amount (which must be higher than the current authorized amount). Upon success, the authorized amount on the transaction is updated to the new amount.
To reduce the authorized amount, use the Reversal API instead.