Beta

Merchant Initiated Payments

Merchant-initiated payments are transactions triggered by the merchant without the customer being present or actively engaged (“off-session”). These payments are typically used in scenarios where the amount is not known at the time of the initial transaction or when a future event—such as a subscription renewal—triggers the payment.

Unlike customer-initiated payments, merchant-initiated payments occur without an active customer session.

Subsequent Recurring Payments

Having successfully processed an initial recurring payment, you are ready to process a subsequent recurring payment. You just need to adhere to the frequency, the expiry, and the amount of the initial payment (your subsequent payments must be less or equal to the initial payment).

Request

Find the API documentation for the request here.

POST /payments/recurring/{payment_id}/subsequent

You can see from the path, that you need to provide the ID of the initial payment. Without this ID, Hellgate® cannot process the payment.

The payload for the request is very straightforward and in the simplest case looks like this:

{
  "amount": 1000,
  "currency_code": "EUR",
  "reference": "Order #12345"
}

Response

Hellgate® responds with a HTTP 200 OK and a JSON payload. There will be no action requirement.

{
  "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"
}

Remarks

• The source of the initial payment is transferred to each subsequent payment.
• For your reference, the initial_payment_id is provided. This is the ID of the initial payment.

Subsequent Unscheduled Payments

Subsequent unscheduled payments are a special case of payments. They are used to process payments that are not scheduled in advance, but rather initiated by the merchant at a later point in time. This is useful for scenarios where the payment amount is not known at the time of the initial payment, or where the payment is triggered by an event that occurs after the initial payment.

Like with recurring payments, it is also the way to get payment credentials from the customers, as they are on-session for the first payment. Subsequent unscheduled payments will be processed in the background without a customer on-session.

Request

Find the API documentation for the request here.

POST /payments/unscheduled/{payment_id}/subsequent

You can see from the path, that you need to provide the ID of the initial payment. Without this ID, Hellgate® cannot process the payment.

Response

Hellgate® responds with a HTTP 200 OK and a JSON payload. There will be no action requirement.

{
  "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"
}

Remarks

• The source of the initial payment is transferred to each subsequent payment.
• For your reference, the initial_payment_id is provided. This is the ID of the initial payment.

Authentication / 3-D Secure

In case 3-D Secure with 3RI is configured for your account, Hellgate® will automatically handle the process.

You can configure the authentication behavior for merchant initiated payments with the authentication_preference field in the request. The following values are supported:

• 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.