Page tree

Search

Skip to end of metadata
Go to start of metadata

When requesting card payments via Computop hosted forms the complexity of 3-D Secure is completely removed from the merchant implementation.

From a merchant point of view the sequence itself does not differ between 3DS authenticated and non-authenticated payments though 3DS requires consideration of additional data elements in the request and response.

Notice about Cookie-/Session Handling

Please note that some browsers might block necessary cookies when returning to Your shop. Here you will find additial information and different solution approaches.

Simplified Sequence Diagram

Payment Request

To retrieve a Computop card form please submit the following data elements via HTTP POST request method to https://www.computop-paygate.com/payssl.aspx.


KeyFormatConditionDescription
1

MerchantID

ans..30

M

Merchant identifier assigned by Computop.
2

MsgVer

ans..5

M

Message version.

Values accepted

  • 2.0
3

TransID

ans..64

M

Transaction identifier supplied by the merchant. Shall be unique for each payment.
4

RefNr

ans..30

O

Merchant’s unique reference number, which serves as payout reference in the acquirer EPA file. Please note, without the own shop reference delivery you cannot read out the EPA transaction and regarding the additional Computop settlement file (CTSF) we cannot add the additional payment data.
5

Amount

n..10

M

Transaction amount in it smallest unit of the submission currency.
6

Currency

a3

M

ISO 4217 three-letter currency code.
7

Capture

ans..6

O

Determines the type and time of payment completion (i.e. dual message systems).

Values accepted:

  • AUTO = completion immediately after authorisation (default value)
  • MANUAL = completion made by the merchant
  • NUMBER = Delay in hours until the completion (whole number; 1 to 696).
8

billingDescriptor

ans..22

O

A descriptor to be printed on a cardholder’s statement. Please also refer to the additional comments made elswhere for more information about rules and regulations.
9

OrderDesc

ans..768

O

Order description.
10

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

priorAuthenticationInfo

JSON

O

Prior Transaction Authentication Information contains optional information about a 3DS cardholder authentication that occurred prior to the current transaction.
13

accountInfo

JSON

O

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

billToCustomer

JSON

C

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

C

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

billingAddress

JSON

C

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

shippingAddress

JSON

C

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.

20subMerchantPFJSONOObject specifying SubMerchant (Payment Facilitator) details.
21

URLNotify

an..256

M

A FQDN URL to submit the final payment result (HTTP POST). The URL may be called up only via port 443. This URL may not contain parameters: In order to exchange values between Paygate and shop, please use the parameter UserData.
22

URLSuccess

an..256

M

A FQDN URL for redirection of the client in case the payment was processed succefully (HTTP POST). The URL may be called up only via port 443. This URL may not contain parameters: In order to exchange values between Paygate and shop, please use the parameter UserData.
23

URLFailure

an..256

M

A FQDN URL for redirection of the client in case the payment could not be processed succefully (HTTP POST). The URL may be called up only via port 443. This URL may not contain parameters: In order to exchange values between Paygate and shop, please use the parameter UserData.
24

UserData

ans..1024

O

If specified at request, Paygate forwards the parameter with the payment result to the shop
25

MAC

an64

M

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


Computop Paygate will return an HTML document in the response body representing the requested card form. The form may be included in the merchant checkout page or used as a standalone page to redirect the cardholder to.



Cardholder authentication and payment authorization will take place once the the cardholder entered all required card details and submitted the form data to Computop Paygate.

Note: In case you are using your own templates (Corporate Payment Page), please make sure you include Cardholder name on your custom template. Cardholder name is mapped to Paygate API parameter "CreditCardHolder". Cardholder name field must not contain any special characters and must have minimal length of 2 characters and maximum length of 45 characters.

When the payment is completed Computop Paygate will send a notification to the merchant server (i.e. URLNotify) and redirect the browser to the URLSuccess resepctively to the URLFailure.


The blowfish encrypted data elements as listed in the following table are transferred via HTTP POST request method to the URLNotify and URLSuccess/URLFailure.

Notice: Please note that the call of URLSuccess or URLFailure takes place with a GET in case of fallback to 3-D Secure 1.0. Therefore your systems should be able to receiver parameters both via GET and via POST.

HTTP POST to URLSuccess / URLFailure / URLNotify

KeyFormatConditionDescription

MID

ans..30

M

Merchant identifier assigned by Computop.

MsgVer

ans..5

M

Message version.

Accepted values:

  • 2.0

PayID

ans32

M

Payment/transaction identifier assigned by Computop.

XID

ans64

M

ID assigned by Paygate for the operation performed on the payment.

TransID

ans..64

M

Transaction identifier supplied by the merchant. Shall be unique for each payment.

schemeReferenceID

ans..64CCard scheme specific transaction ID required for subsequent credential-on-file payments, delayed authorizations and resubmssions.
Statusa..20M

Staus of the transaction.

Values accepted:

  • Authorized
  • OK (Sale)
  • FAILED

In case of Authentication-only the Status will be either OK or FAILED.

Descriptionans..1024MTextual description of the code.
Coden8MPaygate response code.
cardJSONMCard response data.
ipInfoJSONCObject containing IP information. Presence depends on the configuration for the merchant.
threeDSDataJSONMAuthentication data.
resultsResponseJSONCIn case the authentication process included a cardholder challenge additional information about the challenge result will be provided.
UserDataans..1024CIf specified at request, Paygate forwards the parameter with the payment result to the shop
MACan64MHash Message Authentication Code (HMAC) with SHA-256 algorithm

Extended Sequence Diagram