Request a subsequent unscheduled payment.
- The customer does not need to be on-session for this payment.
- If 3RI is enabled on the account, the payment request can include an off-session authentication initiated by the requestor.
The Hellgate Commerce API provides a comprehensive payment orchestration platform designed to streamline and optimize payment processing for modern businesses. Built with flexibility and security at its core, our API enables you to process payments, manage authentications, and handle cardholder data across multiple payment processors without vendor lock-in.
Hellgate Commerce supports four distinct operating models to match your business needs:
The API is organized into logical groups:
https://sandbox.hellgate.io/
https://api.hellgate.io/
These endpoints handle payment processing where the customer is actively present and authorizing the transaction.
Supports multiple payment scenarios:
All customer-initiated payments optionally support 3-D Secure authentication for enhanced security.
These transactions occur without direct customer interaction at the time of payment.
Key use cases:
All merchant-initiated payments must reference a prior customer-initiated transaction for compliance.
The amount given in minor units (e.g. use 700 for 7€). Some currencies do not support minor units (e.g. Japanese Yen). In this case send in the full value, .i.e. 100 for 100 JPY.
The three letter currency code. See: ISO-4217
The preference for the authentication method to be used for the payment.
Preference | Description |
---|---|
NO_3RI | Don't perform 3RI authentication for this payment (Default). |
TRY_3RI | Try to perform 3RI authentication for this payment. If it fails the payment will still be sent for authorization. |
REQUIRE_3RI | Require 3RI authentication for this payment. If it fails the payment will not be sent for authorization. |
https://sandbox.hellgate.io/payments/unscheduled/{id}/subsequent
https://api.hellgate.io/payments/unscheduled/{id}/subsequent
curl -i -X POST \
'https://sandbox.hellgate.io/payments/unscheduled/{id}/subsequent' \
-H 'Content-Type: application/json' \
-H 'X-API-Key: YOUR_API_KEY_HERE' \
-d '{
"amount": 1000,
"currency_code": "EUR",
"authentication_preference": "NO_3RI",
"reference": "Order #12345"
}'
Success response
The preference for the authentication method to be used for the payment.
Preference | Description |
---|---|
NO_3RI | Don't perform 3RI authentication for this payment (Default). |
TRY_3RI | Try to perform 3RI authentication for this payment. If it fails the payment will still be sent for authorization. |
REQUIRE_3RI | Require 3RI authentication for this payment. If it fails the payment will not be sent for authorization. |
The final result of the authentication. It holds in the cardholder authentication data (CAVV) and if there is a network token present, the token authentication data (TAVV).
The amount given in minor units (e.g. use 700 for 7€). Some currencies do not support minor units (e.g. Japanese Yen). In this case send in the full value, .i.e. 100 for 100 JPY.
The amount given in minor units (e.g. use 700 for 7€). Some currencies do not support minor units (e.g. Japanese Yen). In this case send in the full value, .i.e. 100 for 100 JPY.
The amount given in minor units (e.g. use 700 for 7€). Some currencies do not support minor units (e.g. Japanese Yen). In this case send in the full value, .i.e. 100 for 100 JPY.
The amount given in minor units (e.g. use 700 for 7€). Some currencies do not support minor units (e.g. Japanese Yen). In this case send in the full value, .i.e. 100 for 100 JPY.
The three letter currency code. See: ISO-4217
The reasons why a payment failed during processing in Hellgate.
This can be due to processing errors on the side of the processor, as well as errors in the processing of the underlying flow.
In case the failure is due to a processing problem, the transaction history of the payment can give more information on the exact failure details.
The ID of the initial payment.
Only present for subsequent merchant-initiated payments.
This is an optional attribute holding results from eventual pre-processing of the request.
The date when the recurring should expiry.
Only present for recurring payments.
Indicates the minimum number of days between authorisations.
Only present for recurring payments.
The source that was used for the payment.
Type | Description |
---|---|
card | The payment method card was used as source |
An array of split instructions.
Data in this array is only processed on a Hellgate account in the platform operating model. If you are in doubt, please reach out to your account representative.
Type | Description |
---|---|
seller | Sending the given amount to the seller referenced by the merchant_id in the payload. The seller needs to be onboarded to the account and linked to the processor in order to receive funds from a payment split. |
commission | An already existing Hellgate token can be used as source for the payment. |
Definition of the payment use-case for processing
{ "id": "54ba1fdb-7e4e-402b-aebb-66f9d5345cf8", "amount": { "requested": 1000 }, "authentication_preference": "NO_3RI", "created_at": "2023-10-10T00:00:00Z", "currency_code": "EUR", "credential_id": "7d542f79-5f16-44e1-8fff-e8cbaf2597f9", "initial_payment_id": "2c973d90-751e-4e66-a6bf-c53a9a56f93e", "reference": "Order #12345", "source": { "type": "card", "cardholder_name": "Bob Holder", "expiry_month": 12, "expiry_year": 2030, "masked_account_number": "424242XXXXXX4242", "pan_type": "FPAN" }, "status": "processing", "use_case": "SUBSEQUENT_UNSCHEDULED" }
Request a subsequent recurring payment.
The request must to follow the schedule defined by the initial recurring payment.
The amount given in minor units (e.g. use 700 for 7€). Some currencies do not support minor units (e.g. Japanese Yen). In this case send in the full value, .i.e. 100 for 100 JPY.
The three letter currency code. See: ISO-4217
The preference for the authentication method to be used for the payment.
Preference | Description |
---|---|
NO_3RI | Don't perform 3RI authentication for this payment (Default). |
TRY_3RI | Try to perform 3RI authentication for this payment. If it fails the payment will still be sent for authorization. |
REQUIRE_3RI | Require 3RI authentication for this payment. If it fails the payment will not be sent for authorization. |
https://sandbox.hellgate.io/payments/recurring/{id}/subsequent
https://api.hellgate.io/payments/recurring/{id}/subsequent
curl -i -X POST \
'https://sandbox.hellgate.io/payments/recurring/{id}/subsequent' \
-H 'Content-Type: application/json' \
-H 'X-API-Key: YOUR_API_KEY_HERE' \
-d '{
"amount": 1000,
"currency_code": "EUR",
"authentication_preference": "NO_3RI",
"reference": "Order #12345"
}'
Success response
The preference for the authentication method to be used for the payment.
Preference | Description |
---|---|
NO_3RI | Don't perform 3RI authentication for this payment (Default). |
TRY_3RI | Try to perform 3RI authentication for this payment. If it fails the payment will still be sent for authorization. |
REQUIRE_3RI | Require 3RI authentication for this payment. If it fails the payment will not be sent for authorization. |
The final result of the authentication. It holds in the cardholder authentication data (CAVV) and if there is a network token present, the token authentication data (TAVV).
The amount given in minor units (e.g. use 700 for 7€). Some currencies do not support minor units (e.g. Japanese Yen). In this case send in the full value, .i.e. 100 for 100 JPY.
The amount given in minor units (e.g. use 700 for 7€). Some currencies do not support minor units (e.g. Japanese Yen). In this case send in the full value, .i.e. 100 for 100 JPY.
The amount given in minor units (e.g. use 700 for 7€). Some currencies do not support minor units (e.g. Japanese Yen). In this case send in the full value, .i.e. 100 for 100 JPY.
The amount given in minor units (e.g. use 700 for 7€). Some currencies do not support minor units (e.g. Japanese Yen). In this case send in the full value, .i.e. 100 for 100 JPY.
The three letter currency code. See: ISO-4217
The reasons why a payment failed during processing in Hellgate.
This can be due to processing errors on the side of the processor, as well as errors in the processing of the underlying flow.
In case the failure is due to a processing problem, the transaction history of the payment can give more information on the exact failure details.
The ID of the initial payment.
Only present for subsequent merchant-initiated payments.
This is an optional attribute holding results from eventual pre-processing of the request.
The date when the recurring should expiry.
Only present for recurring payments.
Indicates the minimum number of days between authorisations.
Only present for recurring payments.
The source that was used for the payment.
Type | Description |
---|---|
card | The payment method card was used as source |
An array of split instructions.
Data in this array is only processed on a Hellgate account in the platform operating model. If you are in doubt, please reach out to your account representative.
Type | Description |
---|---|
seller | Sending the given amount to the seller referenced by the merchant_id in the payload. The seller needs to be onboarded to the account and linked to the processor in order to receive funds from a payment split. |
commission | An already existing Hellgate token can be used as source for the payment. |
Definition of the payment use-case for processing
{ "id": "54ba1fdb-7e4e-402b-aebb-66f9d5345cf8", "amount": { "requested": 1000 }, "authentication_preference": "NO_3RI", "created_at": "2023-10-10T00:00:00Z", "currency_code": "EUR", "credential_id": "7d542f79-5f16-44e1-8fff-e8cbaf2597f9", "initial_payment_id": "2c973d90-751e-4e66-a6bf-c53a9a56f93e", "reference": "Order #12345", "source": { "type": "card", "cardholder_name": "Bob Holder", "expiry_month": 12, "expiry_year": 2030, "masked_account_number": "424242XXXXXX4242", "pan_type": "FPAN" }, "status": "processing", "use_case": "SUBSEQUENT_RECURRING" }
Modify existing payment transactions after initial authorization. Essential for flexible payment management across all operating models.
Available modifications:
Modifications can be applied across multiple processors, maintaining consistency in multi-processor setups.
Access comprehensive payment transaction data for reporting, reconciliation, and analysis. Critical for all operating models to maintain transaction visibility.
Features:
Access detailed refund transaction data for tracking and reconciliation. Essential for customer service and financial reporting across all operating models.
Provides:
Hellgate allows to process EMVCo 3-D Secure authentication requests as standalone request.
For example, these endpoints can be used to process payment authentication centrally and process the subsequent authorization requests conditionally on different payment processors.
The secion of customer initiated authentications consists of three use-cases:
Use-Case | Description |
---|---|
One Off | A standard situation in which a single payment amount shall undergo 3-D Secure authentication. |
Initial Recurring | An authentication of the first payment in the sequence of recurring payments. |
Initial Installment | An authentication of the first payment in the sequence of installment payments. |
Manage stored payment credentials for repeat customers across all operating models. Essential for subscription services, marketplaces, and ecosystems requiring seamless repeat transactions.
Capabilities:
Hellgate Tokens are powerful instrument to manage card holder data in a PCI/DSS compliant way.
Achieve PCI / DSS compliance in almost no time using our certified managed compliance service.
Transparently use the cardholder data across all connected processors to implement a non lock-in acquiring setup.
For every card which is tokenized on Hellgate, network-tokens can be automatically provisioned. This allows for more secure transactions, better conversion, and ultimately lower processing cost.
All cards stored with Hellgate can be managed via the endpoints in this section.
The CVC2 security code is only kept in an ephemeral cache for a few minutes. The API allows to manage this resource with these endpoints:
Safely handle sensitive cardholder data while maintaining PCI DSS compliance across all operating models. Our compliance service acts as a secure proxy between your systems and payment processors.
Key features:
Hellgate supports Network Tokens with major card schemes.
The lifecycle of network tokens is automatically managed. When activated a network token is automatically provisioned and maintained through its life-cycle.
The use of Network Tokens requires prior activation by your account manager.
Configure and manage merchant accounts based on your chosen operating model. The merchant management capabilities adapt to support all four Hellgate Commerce operating models.
The default model for single businesses. Your account operates as a standalone merchant processing its own transactions.
POST /merchants
disabled)DELETE /merchants/{id}
disabled)In case your precious payment-method data is currently locked into an acquirer processor, Hellgate allows you to migrate the tokens automatically. Currently we support stripe.com, but more processors are on our list. Please ask you account manager for more information.
Detailed documentation on how to migrate your stripe payment methods can be found on the Hellgate Developer Documentation.