You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »



Description of Hosted Payment Page (HPP)

Hosted Payment Page

The Hosted Payment Page (HPP) acts like a proxy allowing the customer to choose between the paymethods offered by your shop.

Credit card payments are then forwarded to the Credit Card Payment Form (PaySSL).

Other paymethods (e.g. PayPal) are formwared to other dedicated payment forms.

Integration

The Payment forms offer the easiest way of integration :

  • Your system just need to request the Payment form from AXEPTA
  • the customer enters the payment data into the form which send them to AXEPTA
  • the payment is processed by AXEPTA automatically
  • and AXEPTA sends a notification to your shop system with the result of that payment process.

You just need to:

  • build the API request initiating the payment process
  • supply URLs for success, failure, back and notification

AXEPTA handles automatically:

  • Validation of customer input data
  • Retry of customer input in case of failure
  • Handling of 3-D Secure authentication form provided by banks for 3-D Secure 1.x and s-D Secure 2.x
  • Automatic handling of soft decline, i.e.: an authorization which requires authentication


You will fin all technical inputs in the section Inputs for developers

Contents



Language of the payment page

The standard BNP Paribas payment page is available in 7 languages : french, english, german, spanish, portuguese, italian and dutch. 

By default, the language of the payment page will match the language used previously by the user, on the merchant's website. However, the user will have the possibility to change the language once he arrives on the payment page thanks to a scrolling menu, on the top right of the page (see below) :



Payment experiences

There are 3 different options to display the payment methods on the Axepta Online payment page:

  • Payment page offering cards only - HPP will call paySSL.aspx
  • Payment page highlighting cards payment - HPP will call paySSL.aspx
  • Payment page offering all payment methods available on the shop (cards payment and alternative payment methods)


Payment page offering cards only

This page shows card payment checkout only and is useful for a merchant who wants to offer payment by cards only (CB, Visa, MasterCard, Amex…).

To make card payments via the payment platform form, please use the following URL:

https://paymentpage.axepta.bnpparibas/payssl.aspx?...

The general parameters of a payment request by card are available in a dedicated document (Please refer to the “card processing” document).


Cusomization capabilities are described in the following page : Integration and customization capabilities

Payment page highlighting cards payment

This page is enriched with a drop-down menu showing alternative payment methods (PayPal, iDEAL, Sofort, Wechat…) for a merchant who wants to highlight card payments but also offers other payment methods.

As this page offers many payment methods at the same time, proceeding to payment should be done using the following URL:

https://paymentpage.axepta.bnpparibas/paymentPage.aspx?...

  • When the user chooses to pay by card, he will be automatically redirected to the specific URL for card payments (payssl.aspx)
  • When the user chooses to pay with another payment method from the drop-down list, he will be redirected to the specific URL (Please refer to the manual of each available payment method).

To activate this display, the merchant must contact the BNP Paribas Helpdesk:


Cusomization capabilities are described in the following page : Integration and customization capabilities


Payment page offering all payment methods available on the shop (cards payment and alternative payment methods)


This page shows all the logos of the available payment methods, so the merchant is not highlighting any payment method. 

As this page offers many payment methods at the same time, proceeding to payment should be done using the following URL:

https://paymentpage.axepta.bnpparibas/paymentPage.aspx?...

 

The user will be automatically redirected to the specific URL of the chosen payment method (please refer to each payment method guide).


This page is displayed to the merchant by default. If the merchant wants to reorganize the payment methods’ order, he must configure the payment methods in the “PayTypes” parameter according to his preferred order. (More information about this parameter in the Definition of parameters values section)


Implementation and customization capabilities

Please refers to Integration and customization capabilities


How to call the payment methods selection page?

To make payment requests via the payment methods selection page, the merchant should send a request to the following URL with HTTPS GET or HTTPS POST:

All details required for payment processing are forwarded as parameters.


Request for a Platform form

The request for a Platform form starts with the correct composition of the parameters which consist of a key and a value which are separated by an equals sign (=). These are so called Name-Value-Pairs (NVP):

MerchantID=YourMerchantID


All parameters are assembled in a character string and separated by the character &:

Amount=100&Currency=EUR&TransID=12345


Notice: Since the characters "=" and "&" are used as separating characters, these characters cannot be transmitted as values. All values which you transmit without BlowFish-encryption must be URL-Encoded.

A correct parameter character string for Platform contains three basic parameters: MerchantID, Len and Data. The parameters MerchantID and Len are unencrypted. Only the Data parameter is Blowfish-encrypted:

MerchantID=YourMerchantID&Len=67&Data=0A67FE96a65d384350F50FF1


The Data parameter contains the sensitive payment details such as amount and currency. The encrypted bytes are Hex-encoded and completed to two characters from the left with a zero. Encryption is via Blowfish ECB and is available to you as source-code and components.

The Len parameter is very important for encryption because it contains the length of the unencrypted(!)  character string in the Data parameter. Since the data quantity to be encrypted is increased by a multiple of 8 in the case of the Blowfish encryption, the correct length of the character string must be known for decryption. Otherwise accidental characters emerge at the end of the character string.

The parameters are transmitted via HTTPS POST or HTTPS GET. The recommended transmit method is HTTPS POST because the parameter character string in the case of GET is attached to the URL, which is limited to 2048 bytes depending on the browser.

Notice: Please note that the maximum length of a payment request is limited to 5120 characters. If you require longer strings please contact Axepta Helpdesk.

The following listings show the development of a payment request. The first listing is the unencrypted parameter character string:

MerchantID=YourMerchantID&TransID=100000001&Amount=11&Currency=EUR&URLSuccess=https://www.shop.de/ok.html&URLFailure=https://www.shop.de/failed.html&URLNotify=https://www.shop.com/notify.cgi&OrderDesc=My purchase


Notice: Please note that a value is to be assigned to each parameter. Do not transmit empty parameters, as this can cause the payment to fail.

This character string is encrypted and transmitted as the Data parameter. The HTTPS GET request for a Platform form for credit card payments looks like this:


Notice: Please note that the parameters are transmitted unencrypted for the purpose of layout of the form.

An HTML form is produced for HTTPS POST and all parameters are transmitted as Hidden Fields. Only the Pay button is visible to the customer.


Example


For additionnal technical information, please refers to Programming basics : Technical implementation and Create an API call and samples to play



Request parameters


The following parameters are mandatory for all payment methods and have to be submitted Blowfish-encrypted within the Data parameter to the payment methods selection page.


Parameter

Format

CND

Description


MerchantID

ans..30

M

ID of merchant.


MsgVer

ans..5

M

Message version.

Values accepted

  • 2.0

TransID

ans..64

M

TransactionID which should be unique for each payment


RefNr

an12

M

Unique reference number


Amount

n..10

M

Amount in the smallest currency unit (e.g. EUR Cent)

Please contact the helpdesk, if you want to capture amounts < 100 (smallest currency unit).


Currency

a3

M

Currency, three digits according to ISO 4217


OrderDesc

ans..384

M

Description of purchased goods, unit prices etc.


MAC

an64

M

Hash Message Authentication Code (HMAC) with SHA-256 algorithm


UserData

ans..1024

O

If specified at request, Payment platform forwards the parameter with the payment result to the shop


AccVerify

a3

O

Indicator to request an account verification (aka zero value authorization). If an account verification is requested the submitted amount will be optional and ignored for the actual payment transaction (e.g. authorization).

Values accepted

  • Yes
11

threeDSPolicy

JSON

O

Object specifying authentication policies and excemption handling strategies
13

accountInfo

JSON

O

The account information contains optional information about the customer account with the merchant
14

billToCustomer

JSON

O

The customer that is getting billed for the goods and / or services. Required for EMV 3DS unless market or regional mandate restricts sending this information.

15

shipToCustomer

JSON

O

The customer that the goods and / or services are sent to. Required if different from billToCustomer.
16

billingAddress

JSON

O

Billing address. Required for EMV 3DS (if available) unless market or regional mandate restricts sending this information.
17

shippingAddress

JSON

O

Shipping address. If different from billingAddress, required for EMV 3DS (if available) unless market or regional mandate restricts sending this information.
18

credentialOnFile

JSON

C

Object specifying type and series of transactions using payment account credentials (e.g. account number or payment token) that is stored by a merchant to process future purchases for a customer. Required if applicable.
19

merchantRiskIndicator

JSON

O

The Merchant Risk Indicator contains optional information about the specific purchase by the customer.

If no shippingAddress is present it is strongly recommended to populate the shippingAddressIndicator property with an appropriate value such as shipToBillingAddress, digitalGoods or noShipment.


Plain

ans..50

O

A value to be set by the merchant to return some information unencrypted, e.g. the MID


Custom

ans..1024

O

The merchant can submit several values separated by | which are returned unencrypted and separated by &.

Custom=session=123|id=456 will change in the answer to Session=123&id=456


URLSuccess

ans..256

M

Complete URL which calls up the Payment platform if the payment has been successful. The URL may be called up only via port 443. This URL may not contain parameters: In order to exchange values between the Payment platform and the shop, please use the parameter UserData.


URLFailure

ans..256

M

Complete URL which calls up Payment platform if payment has been unsuccessful. The URL may be called up only via port 443. This URL may not contain parameters: In order to exchange values between the Payment platform and the shop, please use the parameter UserData.


Response

a7

O

Status response sent by Payment platform to URLSuccess and URLFailure, should be encrypted. For this purpose, transmit Response=encrypt parameter.


URLNotify

ans..256

M

Complete URL which Payment platform calls up in order to notify the shop about the payment result. The URL may be called up only via port 443 It may not contain parameters: Use the UserData parameter instead.


CustomField[n]

ans..50

O
Field that can be used individually by the merchant. Presently 14 fields from CustomField1 to CustomField14 are supported.


These parameters are mandatory for all payment means and must be transmitted and Blowfish-encrypted in the “Data” parameter.

Notice: Please take all further parameters specifically for a payment method from the manual of the respective payment method.











Payment Page global overwiew

The first step of a payment process is offering the user the possibility to select a payment method. To do so, the merchant can choose between 2 different options:

  • Using the BNP Paribas payment page with different option to display the payment means on the page.
  • Creating his own payment page.


Option 1 

BNP Paribas payment page

Option 2

 Merchant’s payment page

Payment means displays’ options

Display 1

Displaying only card payments

Display 2 

Highlighting the card payment and displaying a drop-down menu offering alternative payment methods.

Display 3

Displaying all the available payment methods logos that the merchant offers.

Highest flexibility: The merchant chooses which payment methods he wants to offer in his payment page.

Endpoint

Payssl.aspx

PaymentPage.aspx

For card and alternative payment methods, display3 is configured by default. Please get in contact with the BNP Paribas Helpdesk to activate display2. 

Endpoint depends on payment methods offered by the merchant.

Ex: Card payment: payssl.aspx
PayPal payment : paypal.aspx

Customization

Ø  Logo

Ø  Customizable fields, also called CustomFields (order’s details, customer’s details….)

High flexibility while following some specific conventions (Files names, languages…)

  • No labels