Entersoftone Fintech Help

PayGate Integration Guide

๐ŸŒŸ Introduction

What is PayGate?

PayGate is a complete automated payment system by ENTERSOFTONE designed to streamline the collection of invoices, documents, and general debts. It acts as a bridge between Issuers (businesses that need to collect payments) and Payers (recipients who owe money), leveraging the Greek banking infrastructure (DIAS) to enable secure, automated transactions.

Core Concepts

Before diving into the integration, it's important to understand the key actors and concepts:

Concept

Description

Issuer (ΕκδฯŒτης)

The business that creates and sends payment requests. Must be registered with PayGate.

Payer (Πληρωτฮฎς)

The recipient of the payment request. Does not need to be registered with PayGate.

Payment Request

An electronic payment demand sent to one or more recipients, containing debt details and a unique payment link.

Payment Link

A unique URL that directs the payer to a secure payment portal where they can review and pay the debt.

RF Code

A structured payment reference code used in the DIAS banking system, enabling payments through any Greek bank.

IRIS

The Greek instant payment system, allowing real-time bank-to-bank transfers.

How It Works — The Big Picture

RestAPI

Email with Payment Link

Clicks Link

Selects Bank

Payment Confirmed

Callback / Status API

Issuer's System
ERP / CRM / eCommerce

PayGate Platform

Payer

PayGate Payment Portal

Bank e-Banking

  1. The Issuer sends a payment request through the RestAPI

  2. The Payer receives an email (or link) with the payment details

  3. The Payer clicks the link, reviews the debt, selects their bank, and pays

  4. The Issuer is notified automatically and their system is updated

Key Features

  • Automated Payment Collection — Create and distribute payment requests programmatically

  • Multiple Payment Methods — IRIS instant payments and RF payment codes

  • Flexible Payment Options — Fixed, variable, open amount, and split payment support

  • Real-time Notifications — Callback URLs and polling APIs for instant updates

  • Refund Support — Full and partial refunds through DIAS

  • Easy Registration — Automated Eurobank onboarding for partner platforms

  • ERP-Agnostic — Integrates with any system via RestAPI

Who Should Use This API?

  • ERP/CRM developers automating invoice collection workflows

  • e-Commerce platforms embedding payment links in order flows

  • Partner platforms onboarding their merchants to PayGate via Easy Registration

  • Financial integrators building reconciliation pipelines

๐Ÿ” Authentication & Authorization

Authentication Overview

PayGate uses a three-step authentication model that separates initial registration from ongoing API access. This design ensures that credentials are securely provisioned and that API tokens are short-lived.

Authentication Flow

PayGateIssuer's SystemPayGateIssuer's SystemONE-TIME SETUPBEFORE EACH SESSION (every 50 min)ALL SUBSEQUENT CALLS1. Activate (licenseKey + hostname)applicationKey2. Get Application Token(licenseKey + hostname + applicationKey)access_token (valid 50 min)3. API Call with Bearer tokenResponse

Step 1: Activation (One-Time)

Activation is performed once per issuer. It registers your system with PayGate and returns an applicationKey that acts as a permanent credential.

What you need:

  • activateGuid — Your license key, provided by the PayGate administrator upon service enrollment

  • hostName — The hostname of the calling machine

What you get:

  • applicationKey — A permanent key used in all subsequent token requests

Step 2: Token Generation (Recurring)

Before making any payment-related API call, you must obtain a short-lived access token. Tokens expire after 50 minutes, so your integration should handle token refresh proactively.

What you need:

  • activateGuid — Your license key

  • hostName — Can be any value; the company name is recommended

  • applicationKey — From the Activate step

What you get:

  • access_token — A Bearer token used in the Authorization header of all subsequent calls

Token Management Best Practices

Yes

No

Yes

No

Need to make API call

Token exists
and not expired?

Use existing token

Call Get Application Token

Store token + timestamp

Make API call

Response 401
Unauthorized?

Process response

  • Cache the token and reuse it for multiple calls within the 50-minute window

  • Track the token's creation time and refresh it proactively before expiry (e.g., at 45 minutes)

  • Handle 401 responses by requesting a new token and retrying the call

  • Never hardcode tokens — always generate them dynamically

๐Ÿ“ฅ Payment Request Lifecycle

Payment Request Overview

A Payment Request is the core entity in PayGate. It represents a demand for payment from an Issuer to a Payer. Understanding its full lifecycle is essential for a robust integration.

Payment Request States

Payment Request Created

Full payment received

Partial payment received
(PaymentWay=2, 1st installment)

Remaining amount paid

DueDate or TTL reached

Payment failed
(PaymentWay=1, RedirectType=2)

Issuer cancels request

Pending

Paid

PaidPartially

Expired

Failed

Canceled

Status Code

Status

Description

0

Pending

No payment completed yet.

1

Paid

Payment request fully paid.

2

Paid Partially

Partial payment received (PaymentWay=2, 1st installment).

10

Expired

Payment request has expired (DueDate or TTL).

11

Failed

Payment failed (PaymentWay=1 with RedirectType=2).

Creating a Payment Request

Single Payment Request Flow

PayerPayGateIssuer's SystemPayerPayGateIssuer's Systemalt[Email via PayGate][Email via Issuer]alt[Validation Passes][Validation Fails]IssuerCreate payment for customerPOST Add Payment(sender, receiver, amount, options)Validate request(VRN check, amount rules, date validation)Generate Payment Link + RF CodepaymentRequestId + URL + RFStore paymentRequestId for trackingSend email with payment linkSend payment link through own channelsError response with detailsShow validation errorsIssuer

Key decisions when creating a payment request:

  1. Who sends the email? — PayGate can send it automatically (if ReceiverInfo.Email is provided), or you can send the payment link yourself through your own channels.

  2. What payment flexibility do you want? — Choose a PaymentWay that matches your business needs (see below).

  3. How should the link behave? — Configure RedirectType and TimeToLive to control the payer's experience (see below).

Batch Payment Requests

For scenarios where you need to create many payment requests at once (e.g., monthly billing runs), PayGate supports batch creation. The request body wraps multiple individual payment requests in a Requests array, and the response returns individual results for each.

Understanding Payment Ways

The PaymentWay field controls how much flexibility the payer has when making a payment. Choosing the right option depends on your business scenario.

Yes

No

No

Yes

Yes, allow partial

No, open-ended

Choose PaymentWay

Is the amount
fixed and final?

Can the payer
pay more?

Is there a
known total?

PaymentWay = 1
Fixed Amount
Payer pays exact amount

PaymentWay = 3
Fixed, No Upper Limit
Payer can overpay

PaymentWay = 2
Variable Amount
Payer chooses amount
(2 installments if partial)

PaymentWay = 4
Open Amount (OpenRF)
Payer enters amount freely
Can pay multiple times

PaymentWay

Use Case Example

PaymentAmount

Min/Max Partial

1 — Fixed

Invoice payment for €100.12

100.12

Both 0

2 — Variable

Debt where customer can pay in parts

Total debt amount

Min > 0, Max > Min

3 — Fixed, No Upper Limit

Donation or tip-enabled payment

Base amount

Min = 0, Max ≥ 0

4 — Open Amount

Recurring account top-up

0

Both 0

Understanding Redirect Types & TTL

The RedirectType field, combined with TimeToLive and DueDate, controls the payment link's behavior and what status information is available.

No, just success

Yes, all statuses

No

Yes

Choose RedirectType

Need real-time
status tracking?

Need redirect
after payment?

RedirectType = 2
+ Set TimeToLive
+ Set DueDate
+ Set RedirectUrl
Full status tracking

RedirectType = 0
Basic mode
Only success status via API

RedirectType = 1
+ Set RedirectUrl
Redirects on success
Only success status via API

RedirectType

Status Tracking

Redirect Behavior

Best For

0

Only successful payments (via GetStatus)

No redirect

Background/batch processing

1

Only successful payments (via GetStatus)

Redirects to RedirectUrl on success

e-Commerce checkout flows

2

All statuses (Pending, Paid, Expired, Failed)

Redirects to RedirectUrl on TTL expiry

Real-time payment tracking, kiosk/POS

๐Ÿ’ณ Payment Processing

The Payer's Journey

Once a payment request is created, the payer goes through the following experience:

Issuer's SystemPayGatePayer's Bank (e-Banking)PayGate Payment PortalEmail / LinkIssuer's SystemPayGatePayer's Bank (e-Banking)PayGate Payment PortalEmail / Linkpar[Notify via Callback][Update Status]PayerReceives payment linkClicks linkDisplays debt details(invoices, amount, description)Selects bankRedirects to e-BankingLogs in with credentialsShows pre-filled payment(amount, IBAN, reference โ€” no manual entry needed)Approves payment (e.g., OTP)Confirms paymentRecords paymentPOST to CallBackUrl(paymentRequestId, amount, status)Update payment status to PaidProcess payment notificationPayer

Key points about the payer experience:

  • The payer does not need to be registered with PayGate

  • The payment form is pre-filled — the payer doesn't need to enter amount, IBAN, or reference

  • Payment approval uses the bank's own security (e.g., OTP)

  • The payer can pay via IRIS (instant) or RF codes (standard bank transfer)

๐Ÿ“ฌ Getting Notified About Payments

PayGate offers two complementary mechanisms for learning about payment outcomes. A robust integration should use both.

When you create a payment request with a CallBackUrl, PayGate will POST to that URL whenever a payment action occurs. This is the fastest way to learn about payments.

Issuer's SystemPayGateBankIssuer's SystemPayGateBankUse Status API as fallbackalt[Endpoint responds with Success][Endpoint fails or times out]Payment confirmedRecord paymentPOST to CallBackUrl{"Result": "Success"}Callback delivered โœ“Error / TimeoutCallback failed โœ—

What you receive in the callback:

  • paymentRequestId — To match against your records

  • amount — The amount paid

  • paymentStatus1 for successful payments

  • myBankOrderId — IRIS Order ID (if applicable)

  • rf — RF code (if applicable)

  • paymentDate — When the payment was completed

Your endpoint must respond with:

{"Result": "Success"}

or

{"Result": "Fail"}

For cases where callbacks may fail (network issues, server downtime), or for reconciliation purposes, you can poll PayGate for payment status.

Single Payment Status

Query the status of a specific payment request by its paymentRequestId. Returns the current status plus the last 20 successful payments.

Batch Payment Status Reporting

Query the status of up to 50 payment requests at once, filtered by date range and status. Ideal for reconciliation jobs.

Key constraints:

  • Date range (ReportFrom to ReportTo) cannot exceed 90 days

  • Payments outside the date range won't appear, even if they exist

  • For RedirectType = 2 requests, the status filter is ignored

Yes

No

Yes

No

Payment Occurs

PayGate sends Callback

Callback
received?

Process payment
Update records

Scheduled Reconciliation Job

Poll Status API
for pending requests

New payments
found?

No action needed

Best practices:

  1. Primary: Implement a Callback URL endpoint to receive real-time notifications

  2. Fallback: Run a periodic reconciliation job (e.g., every 15–30 minutes) that polls the Status API for any payments your callback might have missed

  3. Idempotency: Always check if you've already processed a payment before applying it (use paymentRequestId + paymentId as a unique key)

โŒ Cancelling a Payment Request

An Issuer can cancel a payment request that hasn't been fully paid yet. Once canceled, the payment link becomes inactive and the payer can no longer use it.

PayGateIssuer's SystemPayGateIssuer's Systemalt[Request found and cancellable][Request not found or already paid]IssuerCancel payment requestDELETE cancelPayment?requestId={id}Mark as canceledSuccess (errorCode: 0)Payment request canceledError (errorCode + description)Show errorIssuer

When to cancel:

  • The invoice was issued in error

  • The debt has been settled through other means

  • The customer disputes the charge before paying

๐Ÿ’ธ Refund Lifecycle

Refund Overview

PayGate supports refunds for completed payments through the DIAS banking system. Refunds can be full (entire payment amount) or partial (a portion of the payment). The refund process is asynchronous — you submit a request and then poll for the result.

Refund Flow

Payer's BankDIAS Banking SystemPayGateIssuer's SystemPayer's BankDIAS Banking SystemPayGateIssuer's SystemRefund processing is asynchronousloop[Poll for status]alt[Refund approved][Refund rejected]alt[Validation passes][Validation fails]IssuerInitiate refundPOST Refund Insert(processId, type, reason, amount)Validate refund requestrefundId + processIdSubmit refund requestGET Refund Status(processId + refundId)Current statusCredit payer's accountStatus = 3 (Success)Rejection reasonStatus = 4 (Failed) + DIAS errorError code + descriptionIssuer

Refund States

Refund Insert submitted

Request forwarded to DIAS

DIAS confirms refund

DIAS rejects refund

Validation error

Pending

SentToDIAS

Success

Failed

Error

Status Code

Description

0

Error (see error codes)

1

Pending — awaiting processing

2

Sent to DIAS — awaiting response

3

Success — refund completed

4

Failed — DIAS rejected the refund

Refund Rules & Constraints

Rule

Detail

Full refund

Amount must exactly equal the payment amount

Partial refund

Amount must not exceed the remaining refundable amount

No mixing

Cannot submit a full refund if a partial refund was already sent

One at a time

Cannot submit a new refund while one is still active/pending

Payment must be paid

Cannot refund a canceled or unpaid payment

Ownership

Can only refund payments belonging to your organization

Refund Reason Codes

When submitting a refund, you must provide a reason code. FOCR (FollowingCancellationRequest) is the most commonly used and is recommended for testing.

Code

Meaning

FOCR

Following Cancellation Request — Recommended default

AC01

Incorrect Account Number

AC04

Account Closed

AC06

Account Blocked

MS02

By Order of the Beneficiary

MS03

Reason Not Specified

๐Ÿ”— Easy Registration (Partner Onboarding)

Easy Registration Overview

Easy Registration is designed for partner platforms that want to onboard their merchants to PayGate automatically. It integrates with Eurobank's Easy Registration service to handle the bank authentication and account setup without manual intervention.

When to Use Easy Registration

  • You are a software platform (ERP, CRM, e-commerce) that serves multiple businesses

  • You want your merchants to accept payments through PayGate under your partner umbrella

  • You need automated onboarding without requiring merchants to contact PayGate directly

Easy Registration Flow

EurobankPayGatePartner PlatformEurobankPayGatePartner PlatformSTEP 1 โ€” Iframe Authenticationalt[Already Registered][Not Registered]STEP 2 โ€” Get Registration Statusloop[Poll until status is Active or Failed]STEP 3 โ€” Activate & Start UsingMerchant"I want to accept payments"Open iframe URL(redirectUrl + base64 clientKey)Check if merchant is already registeredRedirect to client_url(already onboarded)Redirect to Eurobank loginEnter e-Banking credentialsAuthenticate & authorizeAuthentication completeRedirect to client_urlGET RegistrationStatus?uniqueKey={key}Status (Pending / Active / Failed)POST Activate (ActivateGuid + hostname)applicationKeyPOST Get Application Tokenaccess_tokenPOST Add Payment (using token)paymentRequestId + URL + RFMerchant

Step-by-Step Breakdown

Step 1: Open the Iframe

Construct the iframe URL with your parameters:

https://{impact-url}?redirecturl={client_url}&key={clientkey}

Parameter

Production

Demo

impact-url

paygate.be24.gr/registration

uat-paygate.be24.gr/registration

The clientkey is a Base64-encoded string containing:

SerialNumber;companyVRN;companyCode;apiKey

Component

Description

SerialNumber

Your internal request identifier

companyVRN

The merchant's Tax ID (ΑΦΜ)

companyCode

Your internal company code for the merchant

apiKey

Unique key provided by the PayGate team

Step 2: Poll Registration Status

After the merchant completes authentication, poll the Registration Status endpoint until the status is "Active" or "Failed".

The response includes:

  • ActivateGuid — The license key needed for activation

  • Name — Company name from the bank

  • Iban — The merchant's IBAN

  • Status"Pending", "Active", or "Failed"

Step 3: Activate & Start Using

Once the status is "Active":

  1. Activate the merchant using the ActivateGuid → receive applicationKey

  2. Get Application Token → receive access_token

  3. Create Payment Requests using the token

These steps follow the same authentication flow described in the Authentication section).

Important Notes

โš ๏ธ Error Handling

General Error Structure

All error responses follow a consistent pattern. For payment-related calls, errors are returned as an array of descriptive strings:

{ "errors": [ "MinPartialPaymentAmount must be greater than zero for paymentWay = 2", "PaymentAmount must be less than or equal to PaymentAmount for paymentWay = 2" ] }

For cancel and refund operations, errors use code + label format:

{ "errorCode": -2, "errorLable": "Not found!" }

Common Error Scenarios & Resolution

Scenario

Likely Error

Resolution

Token expired

HTTP 401 Unauthorized

Request a new token via Get Application Token

Wrong VRN

Error code -3

Ensure SenderInfo.VRN matches your organization's license

Invalid PaymentWay + amount combo

Descriptive error in array

Review PaymentWay rules for Min/Max partial amounts

Payment request not found

Error code -2

Verify the paymentRequestId belongs to your organization

Refund on unpaid request

Error code -14

Ensure the payment request has status = 1 (Paid) before refunding

Date range too wide

"Date range must be within 90 days"

Reduce the ReportFrom–ReportTo range

๐Ÿงช Testing & Environments

API Base URLs

Environment

Base URL

Production

https://paygate.be24.gr

Demo (UAT)

https://uat-paygate.be24.gr

Testing Checklist

  • [ ] Successfully activate and obtain applicationKey

  • [ ] Generate and refresh tokens correctly

  • [ ] Create a payment request with PaymentWay = 1 (fixed amount)

  • [ ] Create a payment request with PaymentWay = 2 (variable amount)

  • [ ] Verify payment link opens and displays correct details

  • [ ] Receive callback notification on your endpoint

  • [ ] Poll payment status and verify response

  • [ ] Cancel a pending payment request

  • [ ] Submit a refund and poll for completion

  • [ ] Test batch payment creation

  • [ ] Test token expiry and refresh handling

  • [ ] Test error scenarios (invalid VRN, expired link, etc.)

๐Ÿ“ž Support & Contact

If you need help or have feedback, feel free to reach out.

Contact us: Fintech Team

Last modified: 17 June 2026