Ultimo aggiornamento 19/11/2015

3. Request a new order

3.1 Request URL

  • The request URL in the TEST environment is https://ogone.test.v-psp.com/ncol/test/orderdirect.asp.
  • The request URL in the PRODUCTION environment is https://secure.ogone.com/ncol/prod/orderdirect.asp.

Change "test" to "prod"

Replace “test” with “prod” in the request URL when you switch to your production account. If you forget to change the request URL, once you start in production with real orders, your transactions will be sent to the test environment and will not be processed by the acquirers/banks.

3.2 Request parameters

The following table contains the request parameters for sending a new order request:

Format: AN= Alphanumeric / N=Numeric, maximum allowed amount of characters
Field Description Format Mandatory
Your affiliation name in our system.
AN, 30
Your unique order number (merchant reference).
AN, 40
Name of your application (API) user. Please refer to the User Manager documentation for information on how to create an API user.
AN, 20 (min 2)
Password of the API user (USERID).
Amount to be paid, MULTIPLIED BY 100 as the format of the amount must not contain any decimals or other separators.
N, 15 Yes
ISO alpha order currency code, for example: EUR, USD, GBP, CHF, etc.
AN, 3 Yes
Card/account number.
AN, 21
Expiry date.
Order description.
AN, 100
Customer name.
AN, 35
Customer’s email address.
AN, 50
Signature (hashed string) to authenticate the data (see SHA-IN Signature).
AN, 128
Card Verification Code. Depending on the card brand, the verification code will be a 3- or 4-digit code on the front or rear of the card, an issue number, a start date or a date of birth.
N, 5
Alternative to CVC: date of birth / issue number / etc. (depending on country/bank)
N, 5
Customer’s street name and number.
AN, 50
Customer’s postcode.
AN, 10
Customer’s town/city name.
AN, 40
Customer’s country, e.g. BE, NL, FR, etc.
AN, 2 No
Customer’s telephone number.
AN, 30

Defines the type of requested transaction.

You can configure a default operation (payment procedure) in the "Global transaction parameters" tab, "Default operation code" section of the Technical Information page. When you send an operation value in the request, this will overwrite the default value.

Possible values:
  • RES: request for authorisation
  • SAL: request for direct sale
  • RFD: refund, not linked to a previous payment, so not a maintenance operation on an existing transaction (you can not use this operation without specific permission from your acquirer).


  • PAU: Request for pre-authorisation:
      In agreement with your acquirer you can use this operation code to temporarily reserve funds on a customer's card. This is a common practice in the travel and rental industry.
      PAU/pre-authorisation can currently only be used on MasterCard transactions and is supported by selected acquirers. This operation code cannot be set as the default in your Ingenico ePayments account.
      Should you use PAU on transactions via acquirers or with card brands that don't support pre-authorisation, these transactions will not be blocked but processed as normal (RES) authorisations.
A, 3
Adds a root element to our XML response. Possible values: ‘Y’ or empty.
Y or <empty>
Customer's IP address (for Fraud Detection Module only). If a country check does not need to be performed on the IP address, send 'NONE'.

Request timeout for the transaction (in seconds, value between 30 and 90)

Important: The value you set here must be smaller than the time out value in your system (!)


N, 2

Electronic Commerce Indicator.

You can configure a default ECI value in your account's Technical information page, "Global transaction parameters" tab, "Default ECI value" section. When you send an ECI value in the request, this will override the default ECI value.

Possible (numeric) values:
0 - Swiped
1 - Manually keyed (MOTO) (card not present)
2 - Recurring (from MOTO)
3 - Instalment payments
4 - Manually keyed, card present
7 - E-commerce with SSL encryption
9 - Recurring (from e-commerce)
N, 2

The following parameters are relevant within the scope of the Credential-on-File guideline (COF) by the payment schemes Visa / MasterCard. Detailed information on their usage can be found in dedicated chapter "Processing transactions with stored credentials".

COF_INITIATOR*           Credential-on-file initiator
Possible values:
  • CIT: A transaction initiated by a cardholder
  • MIT: A transaction initiated by a merchant                                                                                                                  
AN          No             
COF_SCHEDULE*  Credential-on-files scheduled (or unscheduled)
Possible values:
  • SCHED: A scheduled transaction
  • UNSCHED: An unscheduled transaction
COF_TRANSACTION* Credential-on-file transaction
Possible values:
  • FIRST: A scheduled transaction
  • SUBSEQ: Subsequent series of transaction 
COF_RECURRING_EXPIRY* Date YYYYMMDD (i.e. 20190914) currently available in TEST only
End date : date of the last scheduled payment of a series
COF_RECURRING_FREQUENCY* Numeric between 2 and 4 digits (i.e. 31, 031 or 0031) currently available in TEST only
Days between payments for a scheduled series.

* Please send the parameter values according to the format as defined in the table. Otherwise the transaction will be blocked by our system.

The list of possible parameters to send can be longer for merchants who have activated certain options/functionalities in their accounts. Please refer to the respective option documentation for more information on extra parameters linked to the option.

The following request parameters are mandatory in new orders:

  • PSWD
  • AMOUNT (x 100)
  • ED
  • CVC

3.3 Test page

Our test page to send order requests in DirectLink can be found here: https://ogone.test.v-psp.com/ncol/test/testodl.asp.

3.4 Excluding specific payment methods

If there are payment methods you don't want a customer to be able to pay with, you can use a parameter to do so.
This is particularly useful for sub-brands, when you want to accept a brand (e.g. MasterCard) but not one of its sub-brands (e.g. Maestro).

The parameter is the following:

Field Usage
List of payment methods and/or credit card brands that should NOT be used.
Values must be separated by a “;” (semicolon).

If a customer tries paying with a card linked to a payment method and/or (sub)brand thT you've excluded BY using the EXCLPMLIST parameter, the error message “Card number incorrect or incompatible” will be returned with the NCERRORPLUS return field.

3.5 Order request using 3-D Secure

Our system supports the usage of 3-D Secure with DirectLink.


  • If you wish to use 3-D Secure with DirectLink, you need to have the D3D option activated in your account.
  • Some acquiring banks require the use of 3-D Secure. Please check with your acquirer if this is the case for you.

3.6 Split credit/debit cards

The functionality to split VISA and MasterCard into a debit and a credit payment method allows you to offer them to your customers as two different payment methods (e.g. VISA Debit and VISA Credit), or you can decide only to accept one of both split brands.

To use the split of credit and debit cards via DirectLink, you need to include the CREDITDEBIT parameter in the fields that you send to the orderdirect.asp page (and therefore also include in the SHA-IN calculation!).

Field Format
CREDITDEBIT "C": credit card
"D": debit card

Related error: When the buyer selects the debit card method but next enters a credit card number, an error code will be returned: ‘Wrong brand/Payment method was chosen’.

If the payment is successfully processed with the CREDITDEBIT parameter, the same parameter will also be returned in the XML response, and/or can be requested with a Direct Query. However, whereas the submitted values are C or D, the return values are "CREDIT" or "DEBIT".

You will also find these return values in transaction overview via "View transactions" and "Financial history", and in reports you may download afterwards.

Configuration in your account

The "split" functionality can also be activated and configured per payment method, in your Ingenico ePayments account. Go to Split Credit/Debit Cards for more information.

3.7 Processing transactions with stored credentials

Credential-on-file (COF) transaction uses existing card details that are already stored by merchants to process the payment. Before initiating a credential-on-file (COF) transaction, the cardholder will first need to authorize the merchant to store the card details. Credential-on-file (COF) mostly applies to recurring payments and states whether the payment is initiated by a cardholder or merchant.

There are two types of credential-on-file (COF) transactions: cardholder-initiated transaction (CIT) or merchant-initiated transaction (MIT). Cardholder-initiated transaction (CIT) will always need to take place before initiating merchant-initiated transaction (MIT).

A cardholder-initiated transaction (CIT) is a transaction where the cardholder is involved in the transaction and personally authenticates the transaction, by means of a signature, 3D-Secure appliance, or presenting IDs.

Example of a cardholder-initiated transaction (CIT):

A cardholder buys a train ticket online and makes a payment. He/She makes the payment with his/her credit card and is being asked to authenticate and authorize the payment. At the same, the cardholder is also asked if he/she wants to save the credit card information related to this payment. If the cardholder agrees, this information can then be re-used in future transactions initiated by the merchant.

A merchant-initiated transaction (MIT) is a transaction initiated by a merchant that acts as a follow-up to a cardholder-initiated transaction (CIT) and a pre-agreed standing order for goods and services purchased by the cardholder. The cardholder does not have to be involved in the transaction.

Example of a merchant-initiated transaction (MIT):

A merchant can automatically initiate a transaction to fulfill a cardholder’s payment on a monthly magazine subscription.

In compliance with the regulations set by Visa and MasterCard for credential-on-file (COF) transaction, new parameters need to be sent to determine the COF transaction.

Impacted if:

  • You are using an Alias
  • You plan to initiate recurring transactions (scheduled or not) after initiating a cardholder-initiated transaction (CIT) for the first time

Required action

By default, these parameters are used in a DirectLink Server-to-Server transaction:



Applies when an alias is used or created

Applies to a first scheduled payment/subscription

MIT-SUBSEQ-UNSCHED Applies when an alias is used or created
MIT-SUBSEQ-SCHED Applies to installment

The default values are flagged if you don't add any parameters. However, if you want to change it, you can overwrite these default values by sending the new parameters. Do not forget to recalculate the SHA signature as well (click here for more information about SHA signature).




COF_INITIATOR CIT A transaction initiated by a cardholder 
  MIT A transaction initiated by a merchant
SCHED A scheduled transaction
  UNSCHED An unscheduled transaction
FIRST First of a series of transactions


Subsequent series of transactions

COF_RECURRING_EXPIRY Date YYYYMMDD (i.e. 20190914) End date : date of the last scheduled payment of a series
numeric between 2 and 4 digits (i.e. 31, 031 or 0031) Days between payments for a scheduled series.

Ingenico ePayments è un provider mondiale di servizi di pagamento digitale, Ingenico Payment Services fornisce una risposta efficace alla complessità di pagamenti qualunque sia il canale: in rete, con il cellulare o in un negozio. Procura soluzioni innovative per il commercio in rete, per quanto riguardano l’aspetto finanziario, l’aspetto commerciale e la complessità dei canali, sostiene i commercianti a gestire, incassare e proteggere i propri pagamenti, prevenendo le frodi ed aumentando le entrate attraverso conversioni più elevate. Ingenico ePayments fa parte del gruppo Ingenico, leader mondiale nel settore di pagamenti in rete.

Questo sito web utilizza i cookie per essere in grado di darvi la migliore esperienza utente. Se non si desidera accettare i cookie, è possibile modificare le impostazioni dei cookie. Cliccate su 'Accetta' per consentire tutti i cookie di questo sito.

Impostazioni dei cookie



I cookies funzionali sono necessari per il funzionamento corretto del sito web. Non è possibile disattivare questi cookie.


I cookies per l’ottimizzazione ci permettono di analizzare l'utilizzo del sito in modo che possiamo monitorare e migliorare il nostro sito.
Questo รจ il livello predefinito.


Cookies di personalizzazione vengono utilizzati per i social media e per personalizzazione avanzata, permettendoci di mostrarvi le informazioni collegate alla vostra azienda.

Esempio delle funzionalità consentite

  • Salvare le preferenze riguardanti il paese
  • Salvare le preferenze riguardanti la lingua

Esempio delle funzionalità non consentite

  • Salvataggio dei dati personali
  • Tracciamento per scopi di remarketing
  • Tracciamento anonimo tramite Google Analytics

Esempio delle funzionalità consentite

  • Salvare le preferenze riguardanti il paese
  • Salvare le preferenze riguardanti la lingua
  • Tracciamento anonimo tramite Google Analytics
  • Tracciamento per scopi di remarketing

Esempio delle funzionalità non consentite

  • Salvataggio dei dati personali
  • Tracciamento per scopi di remarketing

Esempio delle funzionalità consentite

  • Salvare le preferenze riguardanti il paese
  • Salvare le preferenze riguardanti la lingua
  • Tracciamento anonimo tramite Google Analytics
  • Mostrare contenuto in linea con i vostri interessi
  • Mostrare pubblicità in linea con i vostri interessi
  • Tracciamento per scopi di remarketing

Esempio delle funzionalità non consentite

  • Salvataggio dei dati personali