If you are a new merchant, please consider our new interface for this integration mode.

Have a look at its features and possibilities in our dedicated guide.

Ingenico ePayments DirectLink allows you to set up a server-to-server integration with our platform. The customer remains on a page of your own that will securely send the payment data to our servers.

You can also use DirectLink for maintenance of transactions, whether they were initiated in DirectLink or in e.g. Pagina di pagamento ospitata mode.

The graph above shows a transaction flow with DirectLink integration.

Using DirectLink, there is no contact between our system and the merchant's (your) customer. Your system transmits all the information required to make the payment directly to our system in an HTTPS POST request. Our system requests the financial transaction (synchronously or asynchronously) to the relevant acquirer and returns the response to your server in XML format. Your programme reads the response and resumes its processing.

You are therefore responsible for collecting and storing your customer's confidential payment details and must guarantee the confidentiality and security of these details by means of encrypted web communication and server security.

In order to store personal and card data, you need to be PCI compliant.

    The following general procedures and security controls are valid for all DirectLink requests: new order requests, maintenance requests and direct queries.

    The graph above shows a step-by-step transaction flow with DirectLink integration.

    An API (Application Program Interface) user is needed to make DirectLink requests.

    In general it's a user specifically designed to be used by an application to make automatic requests to the payment platform.

    You can create an API user in your Ingenico ePayments account via "Configuration" > "Users". Select "New user" and fill the required fields.

    To make the new user an API user, make sure to enable the "Special user for API (no access to admin.)" box.

    Creation of an API user

    Even though various user profiles are available for an API user, we strongly recommend you to configure this user with the "Admin" profile.
    If you want to limit the rights for maintenance of transactions (refunds, cancellations etc.), you can still change the user profile to e.g. "Encoder".

    If you are not sure, we recommend you to choose the "Admin" profile, otherwise go to User profiles (User Manager) for more information.

    The password for an API user does not have to be changed regularly. This is more convenient when the password has to be hard-coded into your application. However, we recommend you to change the password from time to time.

    For more information about User types and how to change the API user's password, go to User types (User Manager).

    For new order requests, maintenance requests and direct queries, you must send requests with certain parameters to specific URLs. The new order/maintenance/query parameters must be sent in a POST request as follows:

    PSPID=value1&USERID=value2&PSWD=value3&…

    The type/subtype indicating the Media Type in the Content-Type entity-header field in the POST request needs to be "application/x-www-form-urlencoded".

    DirectLink works in “one request-one reply” mode; each payment is processed individually. Our system handles individual transaction requests via DirectLink and can work synchronously (where this option is technically supported), i.e. we wait for the bank’s reply before returning an XML response to the request.

    When we receive a request on our servers, we check the level of encryption and the IP address which the request was sent from.

    DirectLink is built on a robust, secure communication protocol. The API is a set of instructions submitted with standard HTTPS POST requests. We only allow the merchant to connect to us in secure HTTPS mode.
    There is no need for a client TLS certificate.

    The SHA signature is based on the principle of your (the merchant’s) server generating a unique character string for each order, hashed with the SHA-1, SHA-256 or SHA-512 algorithms. The result of this hash is then sent to us in your order request. Our system reconstructs this signature to check the integrity of the order data sent to us in the request.

    Go to SHA-IN Signature (Ingenico ePayments Pagina di pagamento ospitata documentation) - the principle is the same in Pagina di pagamento ospitata and DirectLink mode.

    For DirectLink, the SHA-IN passphrase needs to be configured in the "Checks for DirectLink" section of the "Data and origin verification" tab in your Technical information page.

    For each request, our system checks the IP address from which the request originates to ensure the requests are being sent from your (the merchant’s) server. In the IP address field in the "Checks for DirectLink" section of the "Data and origin verification" tab in your account's Technical Information page, you must enter the IP address(es) or IP address range(s) of the servers that send your requests.

    If the originating IP address has not been declared in the given IP address field, you will receive the error message “unknown order/1/i/”. The IP address the request was sent from will also be displayed in the error message.

    We will return an XML response to your request. Please ensure that your systems parse this XML response as tolerantly as possible to avoid issues in the future, e.g. avoid case-sensitive attribute names, do not prescribe a specific order for the attributes returned in responses, ensure that new attributes in the response will not cause issues, etc.

    • 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.

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

    Field Description
    PSPID

    Your affiliation name in our system.

    Format: AN, 30

    Mandatory

    ORDERID

    Your unique order number (merchant reference).

    Format: AN, 40

    Mandatory

    USERID

    Name of your application (API) user. Please refer to the User Manager documentation for information on how to create an API user.

    Format: AN, 20 (min 2)

    Mandatory

    PSWD

    Password of the API user (USERID).

    Format: AN

    Mandatory

    AMOUNT

    Amount to be paid, MULTIPLIED BY 100 as the format of the amount must not contain any decimals or other separators.

    Format: N, 15

    Mandatory

    CURRENCY

    ISO alpha order currency code, for example: EUR, USD, GBP, CHF, etc.

    Format: AN, 3

    Mandatory

    CARDNO

    Card/account number.

    Format: AN, 21

    Mandatory

    ED

    Expiry date.

    Format: MM/YY or //YY

    Mandatory

    COM

    Order description.

    Format: AN, 100

    Optional

    CN

    Customer name.

    Format: AN, 35

    Mandatory

    EMAIL

    Customer’s email address. If you are requesting 3DSv2.1,  please ensure that the format of the email is valid, otherwise the authentication process will fall back to 3DS 1.0

    Format: AN, 50

    Optional

    SHASIGN

    Signature (hashed string) to authenticate the data (see SHA-IN Signature).

    Format: AN, 128

    Mandatory

    CVC

    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.

    Format: N, 5

    Mandatory

    ECOM_PAYMENT_
    CARD_VERIFICATION

    Alternative to CVC: date of birth / issue number / etc. (depending on country/bank)

    Format: N, 5

    Optional

    OWNERADDRESS

    Customer’s street name and number.

    Format: AN, 50

    Optional

    OWNERZIP

    Customer’s postcode.

    Format: AN, 10

    Optional

    OWNERTOWN

    Customer’s town/city name.

    Format: AN, 40

    Optional

    OWNERCTY

    Customer’s country, e.g. BE, NL, FR, etc.

    Format: AN, 2

    Optional

    OWNERTELNO

    Customer’s telephone number.

    Format: AN, 30

    Optional

    OPERATION

    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 authorization
    • 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).

    Optional:

    • PAU: Request for pre-authorization:
      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-authorization can currently only be used on MasterCard and Visa 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-authorization, these transactions will not be blocked but processed as normal (RES) authorizations.

    Format: A, 3

    Mandatory

    WITHROOT

    Adds a root element to our XML response. Possible values: ‘Y’ or empty.

    Format: Y or <empty>

    Optional

    REMOTE_ADDR

    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'.

    Format: AN

    Optional

    RTIMEOUT

    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 (!)

    Format: N, 2

    Optional

    ECI

    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)

    Format: N, 2

    Optional

         





    If you process recurring payments, you need to add Credentials-on-file (COF) parameters to your request.

    Check out our Alias Manager guide to learn everything about COF-transaction processing.


    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:

    • PSPID and USERID
    • PSWD
    • ORDERID
    • AMOUNT (x 100)
    • CURRENCY
    • CARDNO
    • ED
    • CVC
    • OPERATION


    Complying with your customer’s choice of brand for co-badged cards

    In some cases, a credit card of an international scheme (ie Visa / MasterCard) is also issued for a second, local payment method. Such credit cards are called co-badged cards. 

    If you offer local payment methods on top of the international schemes, you need to offer your customers to choose between the brands a co-badged card is issued for.

    To do so, make sure that


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

    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
    EXCLPMLIST 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.

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

    Important

    • 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.

    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.


    Check out our Alias Manager guide to learn everything about COF-transaction processing.

    Our server returns an XML response to a request:

    Example of an XML response to an order request

    <?xml version=”1.0”?>
    <ncresponse orderID=”99999” PAYID=”1111111” NCSTATUS=”0” NCERROR=”” NCERRORPLUS=”” ACCEPTANCE=”12345” STATUS=”5” ECI=”7” amount="125" currency="EUR" PM="CreditCard" BRAND="VISA"/>

    The following table contains a list of the ncresponse tag attributes:

    Field Description
    ACCEPTANCE Acceptance code returned by acquirer.
    amount Order amount (not multiplied by 100).
    BRAND Card brand or similar information for other payment methods.
    currency Order currency.
    ECI Electronic Commerce Indicator.
    NCERROR Error code.
    NCERRORPLUS Explanation of the error code.
    NCSTATUS First digit of NCERROR.
    orderID Your order reference.
    PAYID Payment reference in our system.
    PM Payment method.
    STATUS Transaction status. (Possible statuses)

    The attribute list may be longer for merchants who have activated certain options (e.g. the Fraud Detection) in their accounts. Please refer to the respective option documentation for further information about additional response attributes linked to the option.

    If you request processing for an already existing (and correctly processed) orderID, our XML response will contain the PAYID corresponding to the existing orderID, the ACCEPTANCE given by the acquirer in the previous processing, STATUS “0” and NCERROR “50001113”.

    A direct maintenance request from your application allows you to:

    • Perform a data capture (payment) of an authorised order automatically (as opposed to manually in the back office);
    • Cancel an authorisation of an order;
    • Renew an authorisation of an order;
    • Refund a paid order.

    Data captures, authorisation cancellations and authorisation renewals are specifically for merchants who have configured their account/requests to perform the authorisation and the data capture in two steps.

    • The request URL in the TEST environment is https://ogone.test.v-psp.com/ncol/test/maintenancedirect.asp.
    • The request URL in the PRODUCTION environment is https://secure.ogone.com/ncol/prod/maintenancedirect.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 working with real orders, your maintenance transactions will be sent to the test environment and will not be sent to the acquirers/banks.

    The following table contains the mandatory request parameters for performing a maintenance operation:

    FieldDescription
    AMOUNT Order amount multiplied by 100.

    This is only required when the amount of the maintenance differs from the amount of the original authorisation. However, we recommend its use in all cases.

    Our system will check that the maintenance transaction amount is not higher than the authorisation/payment amount.
    OPERATION

    Possible values:

    • REN: renewal of authorisation, if the original authorisation is no longer valid.
    • DEL: delete authorisation, leaving the transaction open for further potential maintenance operations.
    • DES: delete authorisation, closing the transaction after this operation.
    • SAL: partial data capture (payment), leaving the transaction open for another potential data capture.
    • SAS: (last) partial or full data capture (payment), closing the transaction (for further data captures) after this data capture.
    • RFD: partial refund (on a paid order), leaving the transaction open for another potential refund.
    • RFS: (last) partial or full refund (on a paid order), closing the transaction after this refund.

    Please note that with DEL and DES that not all acquirers support the deletion of an authorisation. If your acquirer does not support DEL/DES, we will nevertheless simulate the deletion of the authorisation in the back office.

    ORDERID You can send the PAYID or the orderID to identify the original order. We recommend the use of the PAYID.
    PAYID
    PSPID Your account's PSPID
    PSWD Password of your API-user
    SHASIGN Signature (hashed string) to authenticate the data (see SHA-IN-signature)
    USERID Your API-user

    You can test direct maintenance requests here: https://ogone.test.v-psp.com/ncol/test/testdm.asp

    Our server returns an XML response to the maintenance request:

    Example of an XML response to a direct maintenance request
    <?xml version=”1.0”?>
    <ncresponse orderID=”99999” PAYID=”1111111” PAYIDSUB=”3” NCSTATUS=”0” NCERROR=”” NCERRORPLUS=”” ACCEPTANCE=”12345” STATUS="91" amount="125" currency="EUR"/>

    The following table contains a list of the ncresponse tag attributes:

    Field Description
    ACCEPTANCE Acceptance code returned by acquirer
    AMOUNT Order amount (not multiplied by 100)
    CURRENCY Order currency
    NCERROR Error code
    NCERRORPLUS Explanation of the error code
    NCSTATUS First digit of NCERROR
    ORDERID Your order reference
    PAYID Payment reference in our system
    PAYIDSUB The history level ID of the maintenance operation on the PAYID
    STATUS Transaction status (Possible statuses)

    The standard ncresponse tag attributes are the same as those for the XML reply to a new order, except for the extra attribute PAYIDSUB.

    If maintenance is requested twice for the same order, the second request will theoretically be declined with an error “50001127” (This order is not authorised), because the initial successful transaction will have changed the order status.

    A direct query request from your application allows you to query the status of an order automatically (as opposed to manually in the back office). You can only query one payment at a time, and you will only receive a limited amount of information about the order.

    If you need more details about the order, you can look up the transaction in the back office or perform a manual or automatic file download (see Consult your transactions and Batch).

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

    Change "test" to "prod"

    Replace “test” with “prod” in the request URL when you switch to your production account.

    The following table contains the mandatory request parameters to perform a direct query:

    Field
    Description
    ORDERID

    You can send the PAYID or the ORDERID to identify the original order. We recommend the use of the PAYID.

    PAYID
    PAYIDSUB
    You can indicate the history level ID if you use the PAYID to identify the original order (optional).
    PSPID
    Your account's PSPID
    PSWD
    Password of your API-user
    USERID
    Your API-user

    You can test direct query requests here: https://ogone.test.v-psp.com/ncol/test/testdq.asp.

    Our server returns an XML response to the request:

    Example of an XML response to a direct query

    <?xml version=”1.0”?>
    <ncresponse orderID=”99999” PAYID=”1111111” PAYIDSUB=”3” NCSTATUS=”0” NCERROR=”” NCERRORPLUS=”” ACCEPTANCE=”12345” STATUS="9" ECI=”7” amount="125" currency="EUR" PM="CreditCard" BRAND="VISA" CARDNO="XXXXXXXXXXXX1111" IP="212.33.102.55"/>

    The following table contains a list of the ncresponse tag attributes:

    Field
    Usage
    ACCEPTANCE Acceptance code returned by acquirer
    amount Order amount (not multiplied by 100)
    BRAND Card brand or similar information for other payment methods
    CARDNO The masked credit card number
    currency Order currency
    ECI Electronic Commerce Indicator
    IP Customer’s IP address, as detected by our system in a 3-tier integration, or sent to us by the merchant in a 2-tier integration
    NCERROR Error code
    NCERRORPLUS Explanation of the error code
    NCSTATUS First digit of NCERROR
    orderID Your order reference
    PAYID Payment reference in our system
    PAYIDSUB The history level ID of the maintenance operation on the PAYID
    PM Payment method
    STATUS Transaction status

    The standard ncresponse tag attributes are identical to those for the XML reply to a new order, except for the additional attributes PAYIDSUB, CARDNO and IP.

    The attribute list may be longer for merchants who have activated certain options (e.g. the Fraud Detection) in their accounts. Please refer to the respective option documentation for more information on extra response attributes linked to the option.

    If the transaction whose status you want to check was processed with Pagina di pagamento ospitata (hosted payment page), you may also receive the following additional attributes (providing you sent these fields with the original Pagina di pagamento ospitata transaction).

    Field
    Description
    complus*
    A value you wanted to have returned
    (paramplus content)*
    The parameters and their values you wanted to have returned

    *Please check the Variable feedback parameters (Pagina di pagamento ospitata documentation).

    Example of an XML response to a direct query for an Pagina di pagamento ospitata transaction

    <ncresponse orderID=”99999” PAYID=”1111111” PAYIDSUB=”3” NCSTATUS=”0” NCERROR=”” NCERRORPLUS=”” ACCEPTANCE=”12345” STATUS="9" amount="125" currency="EUR" PM="CreditCard" BRAND="VISA" CARDNO="XXXXXXXXXXXX1111" IP="212.33.102.55" COMPLUS="123456789123456789123456789" SessionID="126548354" ShopperID="73541312"/>

    The STATUS field will contain the status of the transaction (see Possible statuses).

    Only the following status is specifically related to the query itself:

    StatusNCERRORNCSTATUS Description
    88 The query on querydirect.asp failed

    The response times for a DirectLink transaction request are generally a few seconds; however, some acquirers may have longer response times.

    If you haven't received a response from our system after 30 seconds, you can send a request to querydirect.asp, asking for the status of your most recent transaction sent to orderdirect.asp. If you receive an immediate reply containing a non-final status for the transaction, there might be issues on the acquirer's end.

    If you haven't received an answer to this direct query request after 10 seconds, there might be issues on our end. You can repeat this request to querydirect.asp every 30 seconds until you see you receive a response within 10 seconds.

    Note
    • This check system will only be able to pinpoint issues at our end if there is also a check at your end to verify that requests are leaving your servers correctly.
    • An issue at our end will not always necessarily be caused by downtime, but could also be as a result of slow response times due to database issues for example.
    • Please use these checks judiciously to avoid bombarding our servers with requests, otherwise we might have to restrict your access to the querydirect.asp page.

    Important

    To protect our system from unnecessary overloads, we prohibit system-up checks which involve sending fake transactions or systematic queries, as well as systematic queries to obtain transaction feedback for each transaction.

    Based on GDPR article 12, 13 & 14, a Data Controller has the obligation to inform its end-customers about the future processing of their personal data. Such information should be made specific based on the type of personal data to be filled-in for a specific transaction (e.g.: selected payment method, controller/processor, acquirer, fraud). The result should be available and visible at the moment of the data collection and the cardholder should be offered with a printable and downloadable version of it.

    Per the GDPR policy, you need to display the information to your customer before they validate their transaction. This information should ideally be displayed on the same page as where your customer fills in their card/account credentials.

    The below privacy policy request allows you to retrieve all the information you need to display to your customer about our services in order to be compliant with the GDPR regulation.

    • The request URL in the TEST environment is https://secure.ogone.com/ncol/test/privacy-policy.asp

    • The request URL in the PRODUCTION environment is https://secure.ogone.com/ncol/prod/privacy-policy.asp
    Change "test" to "prod"
    Replace “test” with “prod” in the request URL when you switch to your production account.

    The following table contains the mandatory request parameters to be sent to your customer regarding the usage of their privacy information:

    Field Format
    Description
    USERID String Your API-user
    PSWD String Your API-user password
    PSPID
    String Your account’s PSPID
    BRAND String (e.g. Visa) Optional: Payment method brand
    You can send this field multiple times to get the result of several brands at once.
    • Sending no brand is the same as sending all your active brands.
    • Empty/wrong formatted brands are ignored.
    LANGUAGE ISO 639-1: Two-letter codes (e.g. FR) Optional: The language in which you want to retrieve the text.
    If not provided, the text will be returned into the merchant configured language.

    You can test direct query requests here: https://secure.ogone.com/ncol/test/privacy-policy.asp

    The following is a list of XML elements and the returned XML responses examples for different outcomes.

    Name Format Description
    Response Complex Root node, always present
    Response.Status String, possible values : Success, SuccessWithWarnings, Error Always present
    Response.Body Complex Present only when Response.Status = Success or SuccessWithWarnings
    Response.Body.Html String / html Empty if Response.Status = SuccessWithWarnings & Response.Warnings.Warning.Code = NoContent
    Response.Errors Complex Present only when Response.Status = Error
    Response.Errors.Error Complex Can occur multiple times inside an <Errors> node
    Response.Warnings Complex Present only when Response.Status = SuccessWithWarnings or Error
    Response.Warnings.Warning Complex Occurs multiple times inside a <Warnings> node
    Response.Errors.Error.Code
    Response.Warnings.Warning.Code
    String, possible values :
    •Inside an <Error> node : Unauthorized, InternalServerError
    •Inside a <Warning> node : NoContent

    Always present in an <Error> or <Warning> node
    Response.Errors.Error.Message
    Response.Warnings.Warning.Message
    String Optional

    If you face Response.Status=Error, please refer to the Response.Errors.Error to fix it.
    The following are two successful examples:
    1. Example of an XML response for success with warnings. This example displays if no privacy information needs to be disclosed to the customer.
      <Response>
      <Status>SuccessWithWarnings</Status>
      <Warnings>
      <Warning>
      <Code>NoContent</Code>
      </Warning>
      </Warnings>
      <Body>
      <Html/>
      </Body>
      </Response>


    2. Example of an XML response for success with content. The example shows a 2 section display
      <?xml version="1.0" encoding="utf-8"?>
      <Response>
      <Status>Success</Status>
      <Body>
      <Html><![CDATA[<ul><li><h2>Title 1</h2><p>Content 1</p></li><li><h2>Title 2 (VISA, American Express)</h2><p>Content 2</p></li></ul>]]></Html>
      </Body>
      </Response>

    For certain payment methods, the parameter values differ from the standard credit card values.

    The following table contains the specific parameter values allowing the transmission of Direct Debit AT transactions via DirectLink.

    Format: AN= Alphanumeric / N=Numeric, maximum allowed amount of characters
    Field Description Format/Value
    CARDNO

    Bank account number

    AN, 21

    Format: XXXXXXXXXXXBLZYYYYY

    XXXXXXXXXXX: account number, numeric, 11 digits.
    YYYYY: Bank code (Bankleitzahl), 5 digits.
    CN Bank account holder’s name AN, 35
    ED Expiry date
    „99/99“ oder „9999“
    OPERATION

    Operation code (Action to be performed)

    A, 3

    Possible values:

    • RES: authorisation
    • SAL/SAS: debit money from the bank account
    • RFD/RFS: refund money (*)
    OWNERADDRESS Address of the account holder AN, 50
    OWNERTOWN City/town of the account holder AN, 40
    OWNERZIP Postal code of the account holder AN, 10
    PM Payment method AN, 25

    “Direct Debits AT”

    (*If the Refund option is available and active, and DTAUS Refunds is available)

    The following table contains the specific parameter values allowing the transmission of Direct Debits NL transactions via DirectLink.

    Format: AN= Alphanumeric / N=Numeric, maximum allowed amount of characters
    Field Description Format/Value
    CARDNO Bank account number Regular Dutch account number: max. 10 alphanumeric characters (if less, left pad with zeros).

    OR

    IBAN account number: max. 35 alphanumeric characters (SEPA)

    CN Bank account holder’s name AN, 35
    ED Expiry date „99/99“ oder „9999“
    OPERATION

    Operation code (Action to be performed)

    A, 3

    Possible values:

    • SAL or SAS: debit money from the bank account
    • RFD or RFS: credit money to the bank account (refund)
    OWNERTOWN City of the bank account holder AN, 40
    PM Payment method

    AN, 25

    “Direct Debits NL”

    Only relevant for SEPA (*) transactions:
    BIC Bank Identifier Code AN, 11
    MANDATEID

    Unique mandate reference.

    Note: If not provided, the ORDERID will be used.

    AN, 35

    No spaces; cannot start or end with a forward slash "/", or contain two consecutive slashes.

    SEQUENCETYPE

    The Direct Debit transaction type

    Note: If not provided, the transactions will be considered as a “one-off” and value "OOFF" will be used.

    Possible values to indicate the Direct Debit transaction type (AN, 4):
    • "FRST": First collection of a series of Direct Debit instructions
    • "RCUR": Direct Debit instructions where the debtor's authorisation is used for regular Direct Debit transactions initiated by the creditor
    • "FNAL": Final collection of a series of Direct Debit instructions (afterwards same MandateID can't be used anymore)
    • "OOFF": Direct Debit instruction where the debtor's authorisation is used to initiate one single Direct Debit transaction
    SIGNDATE

    Date mandate was signed by the buyer.

    Note: If not provided, the transaction date will be used.

    YYYYMMDD

    (*SEPA: Single Euro Payments Area)

    Note: These fields can be returned in the DirectLink XML-response and need to be included in the SHA-IN (and optionally SHA-OUT) calculation.

    For certain payment methods (excluding credit cards), you cannot send new transactions via DirectLink, but you can send certain maintenance operations via DirectLink. This is the case for PostFinance Card, PostFinance E-finance, PayPal Express Checkout and TUNZ.

    When sending maintenance operations, the PM, BRAND, CARDNO and ED fields are not required, so no specific values need to be sent for these payment methods.

    Per informazioni generali su 3-D Secure v2, consulta la nostra guida a PSD2.

    Scopri qui come attivare 3-D Secure in modo sicuro nel processo di pagamento.

    Il flusso delle transazioni è costituito dai seguenti passaggi:

    1. Il cliente accede alle pagine di checkout e finalizza l’acquisto sulla pagina di pagamento.
    2. Ci invii le informazioni sull’ordine e i dettagli di pagamento tramite una richiesta DirectLink, contenente una serie di parametri aggiuntivi.
      • (2’)Opzionale: eseguiamo un controllo antifrode.
    3. Ricevi una risposta XML dalla nostra piattaforma. Sono possibili due scenari.
      • Se la transazione avviene attraverso il flusso senza attriti, la risposta contiene i parametri standard con il feedback finale della transazione. Questo indica il termine del flusso.

      • Se la transazione avviene attraverso il flusso difficile, la risposta contiene il campo aggiuntivo HTML_ANSWER e uno stato di pagamento specifico (STATUS=46). HTML_ANSWER contiene un blocco di codice con codifica in BASE-64.

    4. Aggiungi il blocco di codice decrittografato al browser del titolare della carta. Il titolare della carta viene reindirizzato automaticamente alla banca emittente per l’autenticazione.
    5. Il/la titolare della carta si identifica. Il nostro sistema riceve il risultato dall’emittente.
    6. Based on the result, two scenarios are possible:
      • Se l’identificazione ha avuto esito negativo, reindirizziamo il titolare della carta a DECLINEURL, mettendo fine al flusso. Riceverai il risultato tramite i canali di feedback della modalità Pagina di pagamento ospitata.
      • Se l’identificazione ha avuto esito positivo, inviamo la transazione finanziaria effettiva all’acquirente per l’elaborazione della transazione.
    7. Ti restituiamo il risultato del pagamento. A seconda del risultato dell’acquirente, reindirizziamo il titolare della carta a ACCEPTURL / DECLINEURL / EXCEPTIONURL. Riceverai il risultato tramite i canali di feedback della modalità Pagina di pagamento ospitata.
    8. Se la transazione ha avuto esito positivo, puoi distribuire i beni / i servizi.

    DirectLink with 3-D Secure v2 transaction flowThis graph describes the DIRECTLINK (DPR/D3D) + Fraud transaction flow

    l'eventuale applicabilità del passaggio della responsabilità della transazione dipende dal contratto dell'acquirente. Si consiglia pertanto di verificare i termini e le condizioni con l'acquirente.

    Per elaborare le transazioni con 3-D Secure, invia una serie di parametri obbligatori, consigliati e opzionali alla nostra piattaforma.

    Questi parametri devono essere inclusi nel calcolo SHA.

    Acquisisci e invia parametri

    Devi acquisire i parametri obbligatori / consigliati / opzionali specifici di 3DS nella pagina di pagamento.

    Qui è disponibile un blocco di codice Javascript da utilizzare per acquisire le informazioni del browser.

    <script type="text/javascript" language="javascript">
    function createHiddenInput(form, name, value)
    {
    var input = document.createElement("input");
    input.setAttribute("type", "hidden");
    input.setAttribute("name", name);
    input.setAttribute("value", value);
    form.appendChild(input);
    }

    var myCCForms = document.getElementsByName("MyForm");
    if (myCCForms != null && myCCForms.length > 0)
    {
    var myCCForm = myCCForms[0];
    createHiddenInput(myCCForm, "browserColorDepth", screen.colorDepth);
    createHiddenInput(myCCForm, "browserJavaEnabled", navigator.javaEnabled());
    createHiddenInput(myCCForm, "browserLanguage", navigator.language);
    createHiddenInput(myCCForm, "browserScreenHeight", screen.height);
    createHiddenInput(myCCForm, "browserScreenWidth", screen.width);
    createHiddenInput(myCCForm, "browserTimeZone", new Date().getTimezoneOffset());
    }
    </script>

    Invia questi parametri specifici di 3-D Secure insieme agli altri parametri obbligatori di DirectLink. La nostra piattaforma elaborerà la tua richiesta e ti fornirà una risposta.

    Comprensione delle transazioni rifiutate

    PSD2 migliora la trasparenza del processo di pagamento per te e per i tuoi clienti. Ciò risulta particolarmente utile nel caso di transazioni con stato 2.

    Il nostro parametro di feedback CH_AUTHENTICATION_INFO ti fornisce informazioni dettagliate dagli emittenti quando rifiutano le transazioni dei tuoi clienti.

    Condividi queste informazioni con i tuoi clienti per aiutarli a capire il motivo per cui la loro banca ha rifiutato la transazione. Queste informazioni potrebbero anche aiutarti a recuperare la transazione utilizzando la nostra funzione Soft Decline.

    Per ricevere CH_AUTHENTICATION_INFO sia nella risposta XML che nei tuoi URL di reindirizzamento, seleziona questo parametro nel Back Office tramite, rispettivamente, Configuration > Technical information > Transaction feedback >  DirectLink > Dynamic parameters e Dynamic e-Commerce parameters. Ciò garantirà inoltre che queste informazioni siano visibili nella panoramica della transazione in Operations > View transactions / Financial history.

    Usa CH_AUTHENTICATION_INFO per uno dei due possibili scenari:

    • Se la transazione passa tramite frictionless flow, la nostra risposta XML conterrà questo parametro. Aggiungi di conseguenza le informazioni alla pagina dei risultati della transazione.
    • Se la transazione passa tramite challenge flow, riceverai il parametro tramite i Pagina di pagamento ospitata. Poiché non riceverai le informazioni in tempo per modificare i tuoi URL di reindirizzamento una volta finalizzata una transazione, ti consigliamo di contrassegnare “I would like Ingenico to display a short text to the customer on the secure payment page if a redirection to my website is detected immediately after the payment process.” nel Back Office da Configuration > Technical information > Transaction feedback > eCommerce > HTTP redirection in the browser. La nostra piattaforma reindirizzerà quindi i tuoi clienti alla nostra pagina dei risultati intermedi che mostra le informazioni prima che i tuoi clienti finiscano sui tuoi URL di reindirizzamento.

    Tieni presente che non tutti gli emittenti condividono informazioni sul motivo per cui rifiutano le transazioni. Pertanto, in alcuni casi, il parametro CH_AUTHENTICATION_INFO è vuoto.

    Utilizza i seguenti numeri di carta nel nostro Ambiente di test per simulare una risposta dell’emittente:
    Amex: 349586710563469
    MasterCard: 5111823134937549
    Visa: 4010759044222272

    Elaborazione risposta della piattaforma

    Se la transazione avviene attraverso il flusso senza attriti, la risposta contiene i parametri standard con il feedback finale della transazione. Questo indica il termine del flusso.

    Se la transazione avviene attraverso il flusso difficile, la risposta contiene parametri aggiuntivi. Per avviare l’autenticazione dei clienti, devi elaborare i dati aggiuntivi forniti come descritto di seguito:

    Campo Descrizione
    STATO Nuovo valore: “46” (in attesa di identificazione)
    HTML_ANSWER

    Codice HTML con codifica in BASE-64 da aggiungere nella pagina HTML restituita al cliente.

    Questo tag viene aggiunto come figlio del tag XML globale <ncresponse>. Il campo HTML_Answer contiene il codice HTML che deve essere aggiunto nella pagina HTML restituita al browser del cliente.

    Questo codice caricherà automaticamente la pagina di identificazione della banca emittente in una finestra pop-up nella finestra principale, a seconda del valore del parametro WIN3DS.

    Per evitare qualsiasi interferenza tra i tag HTML inclusi nel contenuto del tag XML HTML_ANSWER e il resto del tag XML restituito come risposta alla richiesta DirectLink, il contenuto HTML_ANSWER è codificato in BASE-64 dal nostro sistema prima di restituire la risposta. Di conseguenza, deve essere decodificato in BASE-64 prima di essere incluso nella pagina HTML inviata al titolare della carta.

    Se l’identificazione ha avuto esito negativo, reindirizziamo il titolare della carta a DECLINEURL, mettendo fine al flusso. Riceverai il risultato tramite i canali di feedback della modalità Pagina di pagamento ospitata.

    Se l’identificazione ha avuto esito positivo, inviamo la transazione finanziaria effettiva all’acquirente.

    A seconda del risultato dell’acquirente, reindirizziamo il titolare della carta a ACCEPTURL / DECLINEURL / EXCEPTIONURL. Riceverai il risultato tramite i canali di feedback della modalità Pagina di pagamento ospitata.

    9.3 Carte di prova

    È possibile usare le seguenti carte di prova per simulare una carta registrata 3-D Secure nel nostro ambiente di prova:

    Flusso senza attriti
    Marchio Numero carta Data di scadenza
    VISA 4186455175836497 Qualsiasi data futura
    Mastercard 5137009801943438 Qualsiasi data futura
    American Express 375418081197346 Qualsiasi data futura
    Carte Bancaire 4150557357382737 Qualsiasi data futura
    Flusso difficile
    Marchio Numero carta Data di scadenza
    VISA 4874970686672022 Qualsiasi data futura
    Mastercard 5130257474533310 Qualsiasi data futura
    American Express 379764422997381 Qualsiasi data futura
    Carte Bancaire 4150550997933993 Qualsiasi data futura

    Nota: è possibile scaricare più numeri di schede di prova qui.

    Se una transazione è bloccata a causa di un errore di identificazione, il risultato della transazione sarà:

    STATUS = 2

    NCERROR = 40001134

    9.4 Esclusioni dalla regola 3DSv2

    Alcune transazioni sono escluse da PSD2. Se una delle tue transazioni è tra queste, 3-D Secure non verrà avviato. Ciò vale anche per le transazioni ricorrenti avviate. Per contrassegnare come tali queste cosiddette transazioni avviate dal commerciante (MIT), devi inviare parametri aggiuntivi alla nostra piattaforma.

    Puoi richiedere di omettere 3-D Secure durante


    Scegli solo uno dei modi per richiedere le transazioni, poiché si escludono a vicenda.

    Flusso senza attriti / difficile e indicazione del flusso preferito

    Puoi aumentare le possibilità di ignorare la SCA, ottenendo quindi un flusso senza attriti, inviando il seguente parametro.

    In base alla tua valutazione del rischio di frode, puoi inviare valori specifici (ad esempio, valutazione di basso rischio: 02, rischio di frode aumentato: 03).

    Obbligatorio ( nel caso di una preferenza per un flusso specifico)

    Parametro Valori
    Mpi.threeDSRequestorChallengeIndicator

    Lunghezza: 2 caratteri
    Tipo di dati: stringa
    Valori accettati:

    • 01 = Nessuna preferenza
    • 02 = Nessuna verifica richiesta
    • 03 = Verifica richiesta: preferenza del commerciante
    • 04 = Verifica richiesta: autorizzazione
    • 05 = Nessuna verifica richiesta [analisi di rischio della transazione già eseguita]
    • 06 = Nessuna verifica richiesta [solo condivisione dati]
    • 07 = Nessuna verifica richiesta [SCA già eseguita]
    • 80-99 = Riservato per l’utilizzo DS

    Puoi persino aumentare le possibilità di un flusso senza attriti e un tasso di conversione più elevato inviando più parametri opzionali.

    Esenzioni di 3DS

    Per ignorare completamente il servizio 3-D Secure, invia i seguenti parametri:

    Parametro Valori
    FLAG3D N = Salto del processo di autenticazione 3DS
    3DS_EXEMPTION_INDICATOR Fornire giustificazioni al salto del 3DS. I valori numerici sono applicabili in base alla transazione

    03 = TRA* emittente
    04 = esenzione per bassi importi
    05 = TRA* Commerciante / Acquirente
    06 = Whitelisting
    07 = Corporate
    08 = Spedizione ritardata
    09 = Autenticazione ritardata (portafoglio certificato)

    Ma sarà sempre l’emittente a decidere se si dovrà eseguire il processo di autenticazione. Se l’emittente insiste sul 3DS, la transazione viene rifiutata.

    Importante

    Le transazioni per le quali 3-D Secure deve essere ignorato possono essere elaborate solo come autorizzazioni (che passeranno allo stato 5 se hanno esito positivo). Per ricevere i fondi per queste transazioni, dovrai effettuarne l'acquisizione in un secondo momento. La transazione acquisita con successo passerà allo stato 9.

    Soft Decline

    A typical flow of a soft declined transaction looks like this:

    1. In your first request, you send FLAG3D=N only and no further authentication parameter. This way you indicate that you wish to skip 3-D Secure. The transaction might be accepted already now.
      If it is rejected by your customer’s bank because it insists on 3-D Secure, we will indicate this in the feedback parameter by sending NCERROR=40001139. The transaction will be put in status 2.
    2. To recover this declined transaction, resubmit the transaction by sending the following parameters to our platform
      1. The standard request for e-Commerce / DirectLink parameters as sent in your first request as a new order
      2. FLAG3D=Y to indicate 3-D Secure needs to be rolled out
      3. The 3DSv2 authentication parameters as described here
      4. Mpi.threeDSRequestorChallengeIndicator=04 to indicate that your customer’s bank insists on 3-D Secure following the Soft Decline

    Your customer will have to pass the 3-D Secure authentication during this second request. Finally, the transaction will reach either status 2 or 9. This depends on both whether your customer passed the authentication and the payment is accepted by both your and your customer’s bank.

    Soft Decline is currently available for payment methods Visa, MasterCard, American Express and Carte Bancaire.

    9.5 Passaggio dalla versione 2.1 alla versione 2.2

    La nuova versione di 3-D Secure (v2.2) in arrivo offrirà ancora più possibilità di ottimizzare la tua integrazione.

    Per l’attuale versione 2.1 di 3-D Secure, questo parametro è facoltativo, ma diventerà obbligatorio con la versione 2.2. Implementarlo fin da ora favorirà una transizione graduale dalla versione 2.1 alla 2.2.

    Parametro Valori

    BROWSERJAVASCRIPTENABLED

    Questo valore booleano indica se i tuoi clienti hanno abilitato JavaScript nel proprio browser quando effettuano un acquisto.

    In base a questo valore, si applicano i seguenti parametri

    • TRUE: i seguenti parametri rimangono obbligatori:

      BROWSERJAVAENABLED
      BROWSERSCREENHEIGHT
      BROWSERSCREENWIDTH
      BROWSERTIMEZONE
      BROWSERACCEPTHEADER
      BROWSERUSERAGENT
      BROWSERLANGUAGE

    • FALSE: i seguenti parametri non sono più obbligatori:
      BROWSERCOLORDEPTH
      BROWSERJAVAENABLED
      BROWSERSCREENHEIGHT
      BROWSERSCREENWIDTH
      BROWSERTIMEZONE

      I seguenti parametri rimangono obbligatori:

      BROWSERACCEPTHEADER
      BROWSERUSERAGENT
      BROWSERLANGUAGE

    Tipo di dati: Boolean

    Valori accettati:
    • TRUE
    • FALSE

    Se non si invia questo parametro, il valore viene pre-popolato a seconda degli altri parametri disponibili.

    Oltre a BROWSERJAVASCRIPTENABLED, la versione 2.2 offre parametri nuovi/migliorati per rendere le transazioni ancora più sicure:

    3DSv1 è il primo protocollo di sicurezza a 3 dimensioni degli schemi di carte. È stato sostituito da v2. Se hai attivato v2, questa sezione non è applicabile.

    Ti consigliamo vivamente di adattare la tua attivazione in base ai requisiti v2. Tuttavia, se non sei ancora pronto, qui sono disponibili le istruzioni per attivare v1.

    Flusso delle transazioni 3-D Secure v1

    Il flusso delle transazioni implica i passi di seguito:

    1. Il cliente accede alle pagine di checkout e finalizza l’acquisto sulla pagina di pagamento.
    2. Ci invii le informazioni sull’ordine e i dettagli di pagamento tramite una richiesta DirectLink, contenente una serie di parametri aggiuntivi.
      • (2’)Opzionale: eseguiamo un controllo antifrode.
    3. Ricevi una risposta XML dalla nostra piattaforma.
      • Se la carta del cliente non è registrata per 3-D Secure, la risposta contiene i parametri standard con il feedback finale della transazione.
      • Se la carta del cliente è registrata per 3-D Secure, la risposta contiene il campo aggiuntivo HTML_ANSWER e uno stato di pagamento specifico (STATUS=46). HTML_ANSWER contiene un blocco di codice con codifica in BASE-64.
    4. Aggiungi il blocco di codice decrittografato al browser del titolare della carta. Il titolare della carta viene reindirizzato automaticamente alla banca emittente per l’autenticazione.
    5. The cardholder identifies herself/himself. Our system receives the result from the issuer
    6. Two scenarios are possible
      • Se l’identificazione ha avuto esito negativo, reindirizziamo il titolare della carta a DECLINEURL, mettendo fine al flusso. Riceverai il risultato tramite i canali di feedback della modalità Pagina di pagamento ospitata.
      • Se l’identificazione ha avuto esito positivo, inviamo la transazione finanziaria effettiva all’acquirente per l’elaborazione della transazione.
    7. Ti restituiamo il risultato del pagamento. A seconda del risultato, reindirizziamo il titolare della carta a ACCEPTURL / DECLINEURL / EXCEPTIONURL. Riceverai il risultato tramite i canali di feedback della modalità Pagina di pagamento ospitata.
    8. Se la transazione ha avuto esito positivo, puoi distribuire i beni / i servizi.
    l'eventuale applicabilità del passaggio della responsabilità della transazione dipende dal contratto dell'acquirente. Si consiglia pertanto di verificare i termini e le condizioni con l'acquirente.

    Invio della richiesta 3-D Secure v1

    Per elaborare le transazioni con 3-D Secure, invia una serie di parametri obbligatori e opzionali alla nostra piattaforma.

    La tabella offre una panoramica dei diversi parametri e del relativo scopo per il processo di autenticazione.

    Questi parametri devono essere inclusi nel calcolo SHA.

    Parameter category Parametri Nome / Descrizione
    Obbligatori

    FLAG3D

    Valore fisso: ‘Y’

    Indica il nostro sistema come eseguire un'identificazione 3-D Secure, se necessario.

    HTTP_ACCEPT*

    Questo parametro è stato sostituito browserAcceptHeader. Do not send it if you are already sending browserAcceptHeader.

    Campo richiesta-intestazione Accetto nel browser del titolare della carta, utilizzato per specificare alcuni tipi di supporti accettati per la risposta. Questo valore è utilizzato dall'emittente per controllare se il browser del titolare della carta è compatibile con il sistema di identificazione dell'emittente. *
    Ad esempio:
    Accetto: */*

    HTTP_USER_AGENT*

    Campo richiesta-intestazione Utente-Agente nel browser del titolare della carta, contenente informazioni sull'agente utente che genera la richiesta. Questo valore è utilizzato dall'emittente per controllare se il browser del titolare della carta è compatibile con il sistema di identificazione dell'emittente. *
    Ad esempio: Agente utente: Mozilla/4.0 (compatibile, MSIE 6.0, Windows NT 5.0)

    ACCEPTURL

    URL della pagina Web da mostrare al cliente quando il pagamento è stato autorizzato (o è in attesa di autorizzazione).

    DECLINEURL

    URL al quale viene reindirizzato il cliente al raggiungimento del numero massimo di tentativi di autorizzazione falliti (10 per impostazione predefinita, sebbene il valore possa essere modificato nella pagina Technical Information, nella sezione "Payment retry" della scheda "Global transaction parameters").

    EXCEPTIONURL

    URL della pagina Web da mostrare al cliente se il risultato del pagamento è incerto.

    LANGUAGE

    La lingua predefinita utilizzata se non è selezionato alcun valore lingua oppure una lingua non valida è:
    en_US (inglese)

    Opzionali

    TP

    Per modificare il layout della pagina "order_A3DS", è possibile inviare un URL/nome di modello con questo parametro. (vedere e-Commerce: Modello dinamico).

    PARAMPLUS

    Field to submit the miscellaneous parameters and their values that you wish to be returned in the post-sale request or final redirection.

    COMPLUS

    Field to submit a value you wish to be returned in the post-sale request or output.

    WIN3DS

    Un modo per mostrare al cliente la pagina di identificazione. Valori possibili:

    • MAINW: consente di visualizzare la pagina di identificazione nella finestra principale (valore predefinito).
    • POPUP: consente di visualizzare la pagina di identificazione nella finestra di popup e alla fine di tornare alla finestra principale.
    • POPIX: consente di visualizzare la pagina di identificazione nella finestra di popup e di rimanere nella finestra di popup.

    Dopo aver inviato questi parametri, la nostra piattaforma elaborerà la tua richiesta e ti fornirà una risposta.

    Elaborazione risposta della piattaforma

    Se la carta del cliente non è registrata per 3-D Secure, la risposta contiene i parametri standard con il feedback finale della transazione. Questo indica il termine del flusso.

    Se la carta del cliente è registrata per 3-D Secure, la risposta contiene parametri aggiuntivi. Per avviare l’autenticazione dei clienti, devi elaborare i dati aggiuntivi forniti come descritto di seguito:

    Campo Descrizione
    STATUS Nuovo valore: “46” (in attesa di identificazione)
    HTML_ANSWER

    Codice html con codifica BASE64 da aggiungere alla pagina html restituita al cliente.

    Il tag viene aggiunto come elemento secondario del tag XML globale <ncresponse>. Il campo HTML_Answer contiene un codice HTML da aggiungere alla pagina html restituita al browser del cliente.

    Il codice carica automaticamente la pagina identificativa della banca emittente in un popup nella finestra principale, in base al valore del parametro WIN3DS.

    Per evitare interferenze tra i tag html inclusi nel contenuto del tag XML HTML_ANSWER, insieme al resto del codice XML restituito come risposta alla richiesta di DirectLink, il contenuto HTML_ANSWER viene codificato con BASE64 dal sistema prima che venga restituita la risposta. Di conseguenza, questo deve essere decodificato con BASE64 prima di essere incluso nella pagina html inviata al titolare della carta.

    Se l’identificazione ha avuto esito negativo, reindirizziamo il titolare della carta a DECLINEURL, mettendo fine al flusso. Riceverai il risultato tramite i canali di feedback della modalità Pagina di pagamento ospitata.

    Se l’identificazione ha avuto esito positivo, inviamo la transazione finanziaria effettiva all’acquirente.

    A seconda del risultato dell’acquirente, reindirizziamo il titolare della carta a ACCEPTURL / DECLINEURL / EXCEPTIONURL. Riceverai il risultato tramite i canali di feedback della modalità Pagina di pagamento ospitata.

    Carte di prova

    È possibile usare le seguenti carte di prova per simulare una carta registrata 3-D Secure nel nostro ambiente di prova:

    Marchio Numero carta Data di scadenza Password
    VISA 4000000000000002 Qualsiasi data futura 11111
    MasterCard 5300000000000006 Qualsiasi data futura 11111
    American Express 371449635311004 Qualsiasi data futura 11111

    Nota: è possibile scaricare più numeri di schede di prova qui.

    Se una transazione è bloccata a causa di un errore di identificazione, il risultato della transazione sarà:

    STATUS = 2

    NCERROR = 40001134

    9.7 Ottieni una panoramica sulle transazioni 3-D Secure

    Per tenere traccia delle tue transazioni e dei loro risultati 3-D Secure, ti offriamo un modo per accedere al tuo report 3DS dal Back Office.

    Dai un’occhiata a questo video che spiega come impostare il report in modo rapido e semplice.

    Domande frequenti

    Nel menu dell'account Ingenico ePayments, è possibile cercare facilmente le transazioni selezionando "Operations" (Operazioni) e facendo clic su "View transactions" (Visualizza le transazioni) o "Financial history" (Storia finanziaria), in funzione del tipo di risultati di transazione cercati.

    Andare alla sezione Consultazione delle transazioni per ulteriori informazioni.

    Per impostazione predefinita, è possibile inviare la merce o fornire il servizio una volta che la transazione ha raggiunto lo stato "9 - Payment requested" (9 - Pagamento richiesto). Tuttavia, anche se lo stato 5 indica un risultato positivo, si tratta solo di una prenotazione temporanea di un importo in denaro sulla carta del cliente. Una transazione in stato 5 deve ancora essere confermata (manualmente o automaticamente) per passare allo stato 9, lo stato positivo finale per la maggior parte dei metodi di pagamento.

    Visitare la sezione Stati delle transazioni per ulteriori informazioni.

    È possibile rimborsare facilmente un pagamento con il pulsante "Refund" (Rimborsa) nella panoramica dell'ordine di una transazione (tramite View transactions). Se l'account lo consente, è inoltre possibile fare i rimborsi con una richiesta DirectLink o caricando un Batch file (per transazioni multiple).

    L'opzione Refunds (Rimborsi) deve essere attivata nell'account.

     

    Per maggiori informazioni, visitare la sezione Mantenere le vostre transazioni.

    Per controllare i dettagli specifici di un ordine/una transazione o eseguire la manutenzione delle transazioni, occorre utilizzare l'opzione View transactions. "Financial history" serve invece al controllo periodico dei fondi in entrata e in uscita.

    Per ulteriori informazioni andare alla sezione di confronto tra le funzioni Visualizza le transazioni e Storico finanziario.

    È possibile eseguire rimborsi solo su transazioni per le quali i fondi hanno già ricevuto (lo stato 9 nel nostro sistema  ) per almeno 24 ore. Una cancellazione o annullamento può essere fatto entro circa 24 ore dopo che lo stato finale è stato ricevuto (stato 9 o 5).

    Per conoscere l'ora di chiusura (cut-off time) dell'acquirente, si consiglia di verificare direttamente con il nostro servizio clienti.