e-Commerce Payment Platform

Confidentiality
All the information in the current document is considered confidential. Using it outside the
context of this consultation or disclosing it to exterior persons is subject to prior approval by
EDPS S.A..
 Revision : 3.1 [2022/03/14] - EDPS Confidential

Table of Contents
1 Introduction.............................................................................................................................................3
1.1 Typical Transaction Flow............................................................................................................3
1.2 Setup Requirements....................................................................................................................5
1.3 Service endpoints........................................................................................................................5
2. Functionality..........................................................................................................................................6
2.1 Information posted for the login request....................................................................................6
2.2 Information posted to the EDPS Secure form............................................................................7
2.3 Information returned to the merchant.........................................................................................8
Appendix..................................................................................................................................................10
Table 1 : BID Descriptions.............................................................................................................10
Table 2 : Typical Transaction Response Codes..............................................................................10
Table 3 : Typical System Error Codes............................................................................................11
A1: HTTP POST to login/session example....................................................................................11
A2: HTTP POST to form example.................................................................................................12
A3: Test Cards................................................................................................................................12

Page 2 of 12
 Revision : 3.1 [2022/03/14] - EDPS Confidential

1 Introduction
This is a functional description of the EDPS secure e-commerce platform for
merchants. It provides the necessary steps needed for setting up the EDPS e-
Commerce platform on the merchant's side and describes the information that
needs to be communicated between the merchant and EDPS in the process of
performing a credit card transaction using the EDPS e-Commerce platform.
In order to make communications secure, all exchanges are encrypted via
the HTTPS protocol. Moreover, a signature mechanism has been set up to validate
and authenticate the data exchange. This a a unique signature that represents
the user and transaction and is based on information received by both the user
and the merchant.

1.1 Typical Transaction Flow

The transaction begins with the user viewing the items he intends to buy in
the merchant's shopping cart page. Once the user presses the checkout button on
the shopping cart page, a login call is made from the merchant's server to the
EDPS eCommerce server and once that is successful the user is redirected to the
EDPS customized payment page where he/she can fill in the credit card data fields
and proceed with the transaction. As soon as the user enters his/her credit card
information and hits the submit button, the transaction is executed and the user is
redirected to a landing page on the merchant's server where he can view the
transaction results.

The redirection to the secure form is performed through an HTTPS POST. The
form includes some fields described hereafter, as well as a one time unique
signature based partly on the submitted fields.

The result of the transaction is returned to the merchant via an HTTPS POST. The
returned form fields will also be described hereafter.

Page 3 of 12
Revision : 3.1 [2022/03/14] - EDPS Confidential

Page 4 of 12
 Revision : 3.1 [2022/03/14] - EDPS Confidential

1.2 Setup Requirements

EDPS e-Commerce platform setup requirements :

 All communication between the merchant's server and the EDPS
eCommerce server must be encrypted with protocol TLS 1.2 or later as per
guidelines set by PCI DSS. Use of the strongest possible ciphers is
recommended. 3DES,MD5,CAMELLIA,AES128, among others, are disabled.
 A client certificate needs to be installed on the merchant's server. This will
be provided by EDPS.
 A server certificate needs to be installed on the merchant's server. This
certificate will ensure that the response returned by EDPS to the merchant
is valid.
 The merchant's server public IP address must be specified beforehand and
will be the only IP address allowed to send transaction requests to the EDPS
host.
 A mockup (a non-functional form) of the credit card form, in order for the
merchant to be able to set the layout and appearance of the form that will
be displayed.
 A URL for a landing page on the merchant's server that will receive the
transaction results.

1.3 Service endpoints

Login/Session URL: https://rtfm.edps.gr:6463/session/

Redirect/Form URL: https://rtfm.edps.gr/form/

Page 5 of 12
 Revision : 3.1 [2022/03/14] - EDPS Confidential

2. Functionality

2.1 Information posted for the login request

Before the merchant can redirect the user to the EDPS secure form, they
must first login to the EDPS payment service. This is a necessary step for each
transaction. In order for the login to be successful the following information need
to be submitted via HTTPS POST to the login URL.

Field Description
mid The merchant ID provided by EDPS to identify the merchant.
txnid An alphanumeric transaction id, min len 6, max len 40. Used to
identify the transaction. It is strongly advised that this number
is different for each transaction attempt (* see notes 2.1.1).
uid A per-login created id to uniquely identify the customer to be
redirected.
amount The transaction amount without dots or commas. for example an
amount of 16,50 would be sent as 1650. A transaction with amount
= 0 will be rejected. The same will happen if the transaction
amount is greater than 999999 (€9999,99).
mode Transaction mode (0: PRODUCTION, 1: TEST)
txnType Optional Field. Send ‘S’ for Sale, ‘P’ for Preauth or nothing for the
default value set in the creation of the profile.
date The transaction date (dd-MM-yyyy).
userdata Optional user data submitted by merchant. It will be returned to
the merchant in the transaction response.
installments Installments for the transaction. 2 numeric digits (01-99).

Notes

2.1.1 Please note that the merchant is strongly advised to save the transaction id,
user id date and amount for each transaction. In addition to the above, the
merchant should also save the unique id for this transaction which can be
obtained from calling the function getUid(), that resides in the keygen include file.
2.1.2 If a transaction has been approved by the bank and the merchant requests a
new transaction with the same txnid and uid of a previous one, a new transaction
will not be created. The merchant will receive the original response that was

Page 6 of 12
 Revision : 3.1 [2022/03/14] - EDPS Confidential

produced by the first transaction. This helps prevent double charges of clients in
cases where the merchant does not receive a transaction response. However it is
strongly advised that the merchant uses a different txnid for each attempt.

2.2 Information posted to the EDPS Secure form

During the redirection of the user to the EDPS secure form, the merchant
must send a number of fields using HTTPS Post.

Field Description
txnid An alphanumeric transaction id, up to 40 digits in length, that the
merchant can use to identify the transaction.
mid The merchant ID provided by EDPS to identify the merchant.
embedded Used in the case of an iframe, in order to disable the “back to
shopping cart” link on the merchant's form. A value of 1 will hide
the link. Default value is 0.
rid The unique id for the stored card. The customer will only have to
add the CVV of the card in order to proceed with the transaction.
Omission of the field leads to saving the card again.
backurl A URL that the user will return to if he decides not to proceed with
the transaction after the redirect to the EDPS form, usually a URL
that will take him back to his/her shopping cart. It will be the result
of the “back to shopping cart” link that appears in the EDPS secure
form.
amount The transaction amount without dots or commas. for example an
amount of 16,50 would be sent as 1650. A transaction with amount
= 0 will be rejected. The same will happen if the transaction
amount is greater than 999999 (€9999,99).
date The transaction date (dd-MM-yyyy).
mode Transaction mode (0: PRODUCTION, 1: TEST)
billingAddr* This is an mandatory 3D Secure field indicating the billing address
of the cardholder.

It is in JSON format (urlencoded) and has the following fields:

billAddrCity (City name, var string, max length 50),

billAddrCountry (ISO 3166-1 numeric, fixed length 3,

Page 7 of 12
 Revision : 3.1 [2022/03/14] - EDPS Confidential

https://en.wikipedia.org/wiki/ISO_3166-1_numeric),

billAddrLine1 (Address line, var string, max length 50),

billAddrLine2 (Address line suppl., var string, max length 50),

billAddrLine3 (Address line suppl., var string, max length 50),

billAddrPostCode (ZIP/postal code, var string, max length 16)

Billing Address example

{
"billAddrCity": "Voula",
"billAddrCountry": "300",
"billAddrLine1": "31, Papagou Street",
"billAddrLine2": "",
"billAddrLine3": "",
"billAddrPostCode": "16673"
}

* See relevant xls file for Greek ISO 3166-2 codes (included in the documentation
package)

2.3 Information returned to the merchant

After the transaction the following information will be transferred to the
merchant via HTTPS form post:

Field Description
aa A transaction id that can be used to identify the transaction across
EDPS systems.
amount The transaction amount.
installments Installments for the transaction. 2 numeric digits (01-99).
postdating Postdating for the transaction. 2 numeric digits (01-99).
auth A six-digit transaction approval code, if the transaction was
successful.
bid A three-digit code that identifies the bank that processed the
transaction. *

Page 8 of 12
 Revision : 3.1 [2022/03/14] - EDPS Confidential

date The transaction date.

pan Credit card number used to perform this transaction. Due to
security restrictions, all but the last four digits will be masked.
rc Response code returned by the bank for this transaction. The
response data type is an2 (alphanumeric string of length 2) as per
the ISO8583 definition of field 39.
stored Indicates whether this is a new transaction response, or a response
for an already completed transaction that didn't reach the
merchant and was stored by EDPS until the merchant posts another
request with the same transaction id (txnid).
time The transaction time.
txnid The transaction id that was used by the merchant to identify the
transaction.
type Card brand (VISA, MASTERCARD, etc).
uid Unique one time transaction/user signature.
rid [RFU] can be ignored
userdata Optional user data submitted by merchant.

* See Appendix Table 1 for bid details.

** See Appendix Table 2 for a description of the most common response codes.

The merchant is strongly advised to check the uid signature, txnid and amount in
order to find a match in his/her own list of pending transactions. The values of
these fields must match the ones the merchant had before initiating a new
transaction.

Page 9 of 12
 Revision : 3.1 [2022/03/14] - EDPS Confidential

Appendix

Table 1 : BID Descriptions

BID BANK NAME

011 NATIONAL BANK OF GREECE
014 ALPHABANK
016 ATTICA BANK
017 PIRAEUS BANK
026 EUROBANK

Table 2 : Typical Transaction Response Codes

This is not an exhaustive list.
Note: The descriptions are not to be shown to the customer, but are for internal
use only.

Response Description
Code
00 Transaction was completed successfully.
05 Generic negative response.
15 Card not supported. This card is not supported by the bank. This
usually occurs for cards that have not been issued by banks in
Greece.
26 Transaction not found
27 Amount error
51 Insufficient funds in cardholder's account
76 Original transaction not found
88 Bank is not responding and transaction attempts result in time-
outs.
91 Service temporarily unavailable.
D* Not authenticated (3DSecure).
Response codes that start with ‘D’.

Page 10 of 12
 Revision : 3.1 [2022/03/14] - EDPS Confidential

Table 3 : Typical System Error Codes

Error Cause
700 Service Disabled
701 Curl Failed
702 Bad or missing txnID received by transient
703 Bad or missing amount received by transient
704 Bad or missing txMode received by transient
705 Bad or missing txnDate received by transient
706 Bad or missing mid received by EDPS
707 Bad or missing txnid received by EDPS
708 Bad or missing uid received by EDPS
709 Bad or missing amount received by EDPS
710 Bad or missing txn mode received by EDPS
711 Bad or missing txn date received by EDPS
712 EDPS Server error
713 Bad user data received by EDPS
714 Bad installments received by EDPS

A1: HTTP POST to login/session example

Data posted to https://rtfm.edps.gr:6463/session/
uid: 64176bcec7a4bf37e68c90e5d927840589c74479
amount: 3
txnid: 190701143042
mid: da319489afacfe0ef0ee857c2bfa46f11f8f6537
mode: 1
installments: 01
date: 03-07-2019
userdata: user-test-data

Page 11 of 12
 Revision : 3.1 [2022/03/14] - EDPS Confidential

A2: HTTP POST to form example

Form data posted to https://rtfm.edps.gr/form/
txnid: 190701143042
backurl: http://merchant-url/checkout-page/
mid: da319489afacfe0ef0ee857c2bfa46f11f8f6537
mode: 1
date: 03-07-2019
amount: 3
embedded: 0 (optional)
billingAddr: %7B%22billAddrCity%22%3A%22Voula%22%2C%22billAddrCountry
%22%3A%22300%22%2C%22billAddrLine1%22%3A%2231%2C+Papagou+Street
%22%2C%22billAddrLine2%22%3A%22another-line%22%2C%22billAddrLine3%22%3A
%22last-line%22%2C%22billAddrPostCode%22%3A%2216673%22%2C%22billAddrState
%22%3A%22A1%22%7D

A3: Test Cards

For testing you can use the following credit cards.
Credit card Expiration Date / CVV Expected Result

4111111111111111 Any, future / Any, 3 digits Always approved

4242424242424242 Any, future / Any, 3 digits Always declined

Page 12 of 12