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
The Issuer sends a payment request through the RestAPI
The Payer receives an email (or link) with the payment details
The Payer clicks the link, reviews the debt, selects their bank, and pays
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
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 enrollmenthostName— 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 keyhostName— Can be any value; the company name is recommendedapplicationKey— From the Activate step
What you get:
access_token— A Bearer token used in theAuthorizationheader of all subsequent calls
Token Management Best Practices
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
Status Code | Status | Description |
|---|---|---|
| Pending | No payment completed yet. |
| Paid | Payment request fully paid. |
| Paid Partially | Partial payment received (PaymentWay=2, 1st installment). |
| Expired | Payment request has expired (DueDate or TTL). |
| Failed | Payment failed (PaymentWay=1 with RedirectType=2). |
Creating a Payment Request
Single Payment Request Flow
Key decisions when creating a payment request:
Who sends the email? — PayGate can send it automatically (if
ReceiverInfo.Emailis provided), or you can send the payment link yourself through your own channels.What payment flexibility do you want? — Choose a
PaymentWaythat matches your business needs (see below).How should the link behave? — Configure
RedirectTypeandTimeToLiveto 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.
PaymentWay | Use Case Example | PaymentAmount | Min/Max Partial |
|---|---|---|---|
1 — Fixed | Invoice payment for €100.12 |
| Both |
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 |
| Both |
Understanding Redirect Types & TTL
The RedirectType field, combined with TimeToLive and DueDate, controls the payment link's behavior and what status information is available.
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 | e-Commerce checkout flows |
2 | All statuses (Pending, Paid, Expired, Failed) | Redirects to | 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:
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.
Strategy 1: Callback URL (Push — Recommended Primary)
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.
What you receive in the callback:
paymentRequestId— To match against your recordsamount— The amount paidpaymentStatus—1for successful paymentsmyBankOrderId— IRIS Order ID (if applicable)rf— RF code (if applicable)paymentDate— When the payment was completed
Your endpoint must respond with:
or
Strategy 2: Status Polling (Pull — Recommended Fallback)
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 (
ReportFromtoReportTo) cannot exceed 90 daysPayments outside the date range won't appear, even if they exist
For
RedirectType = 2requests, the status filter is ignored
Recommended Notification Architecture
Best practices:
Primary: Implement a Callback URL endpoint to receive real-time notifications
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
Idempotency: Always check if you've already processed a payment before applying it (use
paymentRequestId+paymentIdas 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.
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
Refund States
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 |
|---|---|
| Following Cancellation Request — Recommended default |
| Incorrect Account Number |
| Account Closed |
| Account Blocked |
| By Order of the Beneficiary |
| 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
Step-by-Step Breakdown
Step 1: Open the Iframe
Construct the iframe URL with your parameters:
Parameter | Production | Demo |
|---|---|---|
|
|
|
The clientkey is a Base64-encoded string containing:
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 activationName— Company name from the bankIban— The merchant's IBANStatus—"Pending","Active", or"Failed"
Step 3: Activate & Start Using
Once the status is "Active":
Activate the merchant using the
ActivateGuid→ receiveapplicationKeyGet Application Token → receive
access_tokenCreate 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:
For cancel and refund operations, errors use code + label format:
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 |
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 |
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 |
|
Demo (UAT) |
|
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