Get Payment Session
Test this endpoint live
Open the same request directly in API Explorer.
Server URL
Retrieve the current state and details of a specific payment session. This endpoint can be used to look up a session by its ID and inspect its lifecycle, including whether it is still pending, in progress, completed, or expired. :::warning Avoid polling This endpoint is subject to <a href="/guides/rate-limits">rate limits</a> and must not be used for continuous polling. Instead, you should rely on the `notificationUrl` provided during session initialization to receive the outcome of the payment. This is the primary and recommended integration pattern. ::: Use this endpoint as a fallback mechanism - for example, if you did not receive a webhook or need to manually verify the final state of a session.
Authorization
BearerAuth In: header
Path Parameters
ID of the session to look up.
uuidHeader 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.
Response Body
application/json
application/json
application/json
application/json
Initialize Payment Session
Initializes a new payment session with the ePay Payments API. This endpoint requires a valid ApiKey and must be called from the server side to ensure the ApiKey is never exposed client-side. You’ll receive the outcome of the payment session 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. We recommend a minimum timeout of 5 seconds. Required or configurable fields In the ePay backoffice, under Advanced Point of Sale Settings, you can set default values for many session initialization parameters. This allows you to manage your setup without updating your code. Each property must be defined either in the backoffice or in the API request. If a value is provided in the API request, it overrides the backoffice default. The following fields can be configured: - scaMode - timeout - instantCapture - processor - maxAttempts - notificationUrl - successUrl - failureUrl - exemptions Note: Only a subset of these fields are strictly required for the API request. The table below indicates which fields are mandatory or optional.
MIT Authorization
Batching and Rate limits ePay strongly recommends merchants to implement the MIT Batch Authorization endpoint over the single MIT authorization endpoint. Please review our rate limits before you begin your implementation. A MIT (Merchant-Initiated Transaction) is a payment initiated by the merchant, typically based on a previously established agreement, such as a subscription. 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. Use a MIT authorization when the customer has agreed to let the merchant charge them automatically. For example, monthly subscription payments must be handled using MIT. MIT is not suitable when the customer starts the payment themselves, like clicking a “Pay Now” button. For more information about the differences between CIT (Customer-Initiated Transaction) and MIT, see our Core Concepts page. All MIT transactions are processed asynchronously and cannot run in real time. Most are completed within a few seconds, but ePay does not guarantee processing times. Some payment methods, such as Vipps MobilePay, may take several days to complete, depending on the method’s processing rules. If you want to offer your customers the ability to store their cards for faster checkout in the future, you must use CIT transactions. In such cases, you are required to provide a customerId when creating the payment. This ID links the stored card to the customer and enables quick-checkout functionality in future sessions. We recommend a minimum timeout of 5 seconds.