NotificationWebhook
The notification webhook is sent to the merchant’s configured endpoint when a transaction attempt has been completed, regardless of whether the transaction succeeded or failed. **Delivery and Retry Policy** - The receiving system must respond with standard HTTP `200 OK`. - If no `200 OK` is received, the webhook will be retried with exponential backoff. - Retry strategy: - Attempt 1: immediate (0 seconds). - Attempt 2: immediate (0 seconds). - Attempt 3+: delayed by `2^attempt` seconds. - Maximum delay capped at 3 hours. - Retries stop after 25 attempts. - Each webhook request has a strict timeout of 5 seconds. - Merchants should always acknowledge quickly and process business logic asynchronously. Failure to comply may result in the endpoint being moved to a low-priority queue. **Headers and Authentication** - Every webhook includes an `Authorization` header that must be validated to ensure the request originated from ePay. - By default, ePay issues a random Bearer token at account creation. This token, and the authorization scheme (`Bearer` vs `Basic`), can be managed in the ePay Backoffice. - No additional signatures or payload signing is applied. Verification relies exclusively on the `Authorization` header.
The ID of the transaction
"LDG7M4WW44G"The ID of the associated subscription
uuid"0197c07b-3f6d-7be2-b848-702b08958128"The ID of any associated subscription billing charge. Will be null if the transaction was not an automatic charge made on a billing agreement.
uuid"019a727b-987f-7768-a59e-71af920ef81f"The current state of the transaction. See our <a href="/get-started/core-concepts">Core Concepts</a> page.
"PENDING""PROCESSING""SUCCESS""FAILED"If the transaction has failed, this contains the associated error code explaining what went wrong.
A nullable object containing any known external status codes, such as the status code from the acquirer or the network. This can be useful for merchants who want to be able to react to very specific rejection reasons.
The time of creation
date-timeThe ID of the associated session. This will be null for any MIT transactions.
The ID of the associated payment method
uuidThe type of the payment method.
"CARD""VIPPS_MOBILEPAY""MOBILEPAY_ONLINE""APPLE_PAY""GOOGLE_PAY""SWISH""VIABILL""ANYDAY""KLARNA""CARD"The sub type of the associated payment method. For card based payments, this will contain the name of the scheme, such as `Visa` or `Mastercard`. The card scheme name formatted with a uppercase starting character. For non-card based payments the field vary depending on the requirements of the payment method.
"Visa""Mastercard""Maestro""Dankort""VisaDankort""Discover""UnionPay""Electron""Amex""JCB""Visa"The expiration date of the associated payment method. Although payment cards are specified by a month and year (MM/YY), this value is returned as a full date (YYYY-MM-DD) representing the **last day of the expiration month**. Example: `"2030-05-31"` for a card expiring in May 2030.
dateA cardholder friendly text to help them identify the payment method. For cards this will be a masked version of the card number.
Contains the entered cardholder name of the optional "name" field. Will be null if the field is not rendered.
The SCA mode of the transaction.
"SKIP""NORMAL""FORCE"The merchant customer id of the transaction. This field is required to enable advanced features such as storing a card for later reuse. Do not use any "guest" customer ids. Customer ids must be unique for each customer and must be protected by authentication.
The transaction amount in minor units (e.g., 1095 = 10.95 DKK)
The applied transaction fee in minor units. The fee is included in the `amount` field. To get the original amount you must subtract `fee` from `amount`. Fees are only applied if surcharge is configured in the ePay backoffice. <br/><br/> Fees are calculated during transaction processing and as such is always 0 when initially created during MIT transactions.
The currency of the transaction in ISO 4217 alpha-3. DKK for danish kroner.
The instant capture mode.
"OFF""VOID""NO_VOID"The URL to receive webhook notifications of any transaction attempts. May contain templating variables.
urilength <= 1024The ID of the associated point of sale
uuidThe merchant reference of the transaction, this is often used for the order id.
The text to show on the cardholder bank statement
1 <= length <= 39The list of exemptions to apply when possible. Note that exemptions may shift liability from the issuer to the merchant.
[
"LVT",
"TRA"
]A list of pass-through parameters that will be sent back to the merchant for following any webhooks
The ip (ipv4/ipv6) of the cardholder making the transaction. The IP is captured by ePay at the initialization of the transaction client-side. Can be empty.
"52.212.176.122"The detected origin country (Alpha-2) based on the `clientIp` property. Can be empty. - Data derived from GeoLite2 by [MaxMind](https://www.maxmind.com).
"DK"The type of transaction.
"PAYMENT""PAYOUT""MOTO"The total amount that has been approved on this transaction. This is the amount the customer’s bank has set aside for the payment, but it has not necessarily been taken from their account yet.
0 <= value25000The total amount that has actually been charged and taken from the customer. This is the portion of the authorized amount that has been finalized and will be transferred to you.
0 <= value15000The total amount that has been returned to the customer after being captured. This represents money that was previously charged but has since been given back.
0 <= value7500The total amount that was canceled before it was charged. This reduces the authorized amount so that it will never be captured or taken from the customer.
0 <= value3000The amount that is still authorized but not yet used. This is the portion that can still either be captured (charged) or voided (canceled).
0 <= value8000The total amount that has been paid out to a recipient. This is only used for payout transactions (sending money out), not for regular customer payments.
0 <= value0The name of the used acquirer / processor of the transaction
"shift4"The merchant category code registered on the agreement. Note `4514` is the default code when none is registered or when not relevant.
"4514"The ID of the payment session
uuidThe subscription id related to the session, this can either be a new ID for new subscriptions or the given ID of a previous subscription which needs to be updated.
uuidThe transaction amount in minor units (e.g., 1095 = 10.95 DKK)
Pass-through data which will be returned back to the merchant in any webhook.
List of exemptions to apply when available. Note exemptions may cause liability shift from the issuer to the merchant.
List of allowed payment methods to use for this session. If left empty, all payment methods will be allowed. This is useful for controlling which payment methods are visible in the payment window. If only 1 payment method is allowed and it is redirect-based, such as `VIPPS_MOBILEPAY`, the user will be automatically redirected from the payment window to the MobilePay payment page, without the user having to click anything. If the user then cancels the MobilePay payment, they will be redirected back to the `returnUrl` (Or the `failureUrl` if the `returnUrl` is not specified) instead of going back to the payment window.
[
"CARD",
"VIPPS_MOBILEPAY"
]The currency of the payment. For Danish Kroner defined as DKK.
^[A-Z]{3}$The expiration time of the payment session. After this time the session can no longer be used and a new session must be created.
date-timeThe instant capture mode.
"OFF""VOID""NO_VOID"The maximum number of transaction attempts allowed for the session
The current number of transaction attempts so far.
The minimum age required. If not null and ePay Verify is enabled on your account, the cardholder will be prompted to verify their age using local online IDs such as MitID in Denmark.
Is true once the customers age has been verified to be at least equal to `minimumAge` parameter.
Boolean flag to enable / disable receiving webhook notifications for failed transactions.
Boolean flag to enable / disable receiving webhook notifications for sessions that reach the expired state.
Boolean flag to enable / disable dynamic amounts, allowing the client to determine the transaction amount. This is generally not recommended for most merchants.
The URL to receive webhooks related to transaction attempts
uriOptional URL to receive a webhook just before authorization is attempted. Can be used to update or reject the transaction. This is often used by merchants integrating external risk tooling to trigger 3DS challenges depending on the payment.
uriThe URL to redirect the client on successful payment attempts
uriThe URL to where the browser is returned, when clicking the `back` button in the Payment Window. This overrides the default defined in the payment window configuration and supports url templating. Max length is `1024`. <div class="theme-admonition theme-admonition-info alert alert--info"> Only used in Payment Window integrations. </div>
uri1 <= length <= 1024The URL to redirect the client on failed payment attempts when no more attempts are possible.
uriThe URL to redirect the client on failed payment attempts when more attempts are possible. If null, then failureUrl is used instead.
uriThe ID of the cardholder. This field is required to enable stored cards. Do not use any "guest" customer ids. Customer ids must be unique for each customer and secured behind authentication.
The ID of the associated point of sale
uuidThe transaction reference - Typically the order id.
The state of the transaction
"PENDING""PROCESSING""COMPLETED""EXPIRED"The text to display on the cardholders bank statement
1 <= length <= 39The chosen SCA mode. This can be used to control the level of cardholder authentication performed before the transaction is authorized.
"SKIP""NORMAL""FORCE"The number of minutes the session is available.
The time of creation
date-timeThe ID of the subscription
uuid"01929a94-5fce-7ccc-a7e4-7e9249133b39"The ID of the associated payment method
uuid"01924756-d1f6-738d-8040-90d76cedf01f"The currency of the original transaction which created the subscription. This is used as the default currency for new MIT transactions, if no currency is given.
^[A-Z]{3}$"DKK"The id of the merchant customer
"User159"The ID of the associated point of sale used during the creation of the subscription
uuid"0192473a-e381-705c-b61c-fc2ac9624afc"The merchant reference for the subscription.
"reference-1"An optional description which can be assigned to the subscription. Can be used to help human operators to link or understand which subscription it is.
The current state of the subscription. See our <a href="/get-started/core-concepts">Core Concepts</a> page.
"PENDING""ACTIVE""INVALID""DISABLED""ACTIVE"The type of subscription. `SCHEDULED` is used for fixed interval charges such as a monthly subscription fee. `UNSCHEDULED` is used for varying transaction intervals such as pay-as-you-go solutions such as parking or bike renting.
"SCHEDULED""UNSCHEDULED""SCHEDULED"The expiration date of the subscription. ePay does not enforce this expiration, but uses it in the processing of transactions which may improve approval rates.
date"2050-01-01"Interval configuration. It can only be present when type equal `SCHEDULED`. A `frequency=2` and `period=WEEK` means one charge for every two weeks.
The time of creation
date-timeBoolean indicator which is true when the transaction is rejected due to failing SCA such as a 3DS challenge with MitID.
falseThe type of SCA performed during the transaction.
"3DS""DELEGATED""UNKNOWN""3DS"The level of verification performed during the transaction. The value will be `CHALLENGED` if the customer was prompted with challenges such as MitID login.
"NONE""FRICTIONLESS""CHALLENGED""UNKNOWN""FRICTIONLESS"Info about the card used during the transaction. Is only available for card based payments.
The masked account number of the paying card. If the transaction is token based, like ApplePay, this will instead contain the TAN (Token PAN).
"12345678XXXX1234"The month the card expires in. A card expires at the end of the month.
"07"The year the card expires in.
"35"The "Primary Account Reference" is a unique non-sensitive reference to the specific card. This will have the same value for any payment made with the same card even across wallets such as ApplePay. This can be used for loyalty systems or fraud prevention systems which needs to uniquely identify cards. The value is not always available. Availability depends on the used acquirer.
"8F1B7C2QX4Z9N3V6M2R0K8YD5LJTPH"The name of the card issuer (Bank)
"Danske Bank"The network scheme such as `Visa` and `Mastercard` of the card
"Visa"The alpha-2 code of the country the card was issued in
"DK"The customer segment the card is issued to. This can be used to identify consumer vs business cards.
"consumer""business""payouts""consumer"The type of funding behind payments made from the card. This can be used identify debit vs credit cards.
"debit""credit""prepaid""debit"