Maintenance Work Notice!

We will carry out maintenance work on this documentation on Tuesday, 15.06.2021 between 3 pm and 4 pm CEST. Thank you for your understanding.

Page tree

Search

Skip to end of metadata
Go to start of metadata

Overview

A Silent Order Post or Direct Post is a transmission method where form data from a merchant website are getting directly posted to a third-party server. This is commonly achieved through the form action attribute that specifies the URL the data are sent to.


Sensitive data such as card details can be captured within a merchant’s website without being processed by the merchant server as the POST is submitted silently. The URL endpoint in Computop Paygate to receive Silent Order Post requests is referred to as PayNow.

<form action="../payNow.aspx" method="post">


This approach is very similar to Computop hosted payment forms and leaves the merchant in full control of the checkout experience as all website elements are delivered from the merchant’s server.


PCI-DSS Considerations

Merchants processing card transactions using the Silent Post model must submit the PCI DSS Self-Assessment Questionnaire (SAQ) A-EP. This SAQ is more comprehensive and thus might require more time and resources in comparison to SAQ A applicable to merchants that use hosted payment pages. However, merchants should always consult with their acquirer to evaluate the level of compliance required and refer to the PCI DSS guidelines. This does not affect the use of pseudo card numbers which is possible without submitting the SAQ questionaire.

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.

Sequence Diagram

Payment Request

Please POST the form data as outlined in table below to https://www.computop-paygate.com/payNow.aspx.

Form Elements


Data ElementLegacy ElementDescription
1

MerchantID

--

Merchant identifier assigned by Computop.

2

Len

--

The length of the original encrypted with Blowfish.

3

Data

--

Blowfish encrypted data.

4

number

CCNr

Card number.

5

securityCode

CCCVC

Card security value.

6

expiryDate

CCExpiry

Card expiry in format YYYYMM.

7

brand

CCBrand

Card network.

8

cardholder

CreditCardHolder

Name of the cardholder as printed on the card.

(- Computop will continue to support the legacy form data fields that are currently in use. -)

Data


KeyFormatConditionDescription
1

MerchantID

ans..30

M

Merchant identifier assigned by Computop.

2

MsgVer

ans..5

M

Message version.

Accepted values:

  • 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

browserInfo

JSON

M

Accurate browser information are needed to deliver an optimized user experience. Required for 3DS 2.0 transactions.

14

accountInfo

JSON

O

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

15

billToCustomer

JSON

C

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

16

shipToCustomer

JSON

C

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

17

billingAddress

JSON

C

Billing address. Required (if available) unless market or regional mandate restricts sending this information.

18

shippingAddress

JSON

C

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

19

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.

20

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.

21

URLNotify

an..256

M

A FQDN URL to submit the final payment result (HTTP POST).

22

URLSuccess

an..256

M

A FQDN URL for redirection of the client in case the payment could not be processed succefully (HTTP POST).

23

URLFailure

an..256

M

A FQDN URL for redirection of the client in case the payment could not be processed succefully (HTTP POST).

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

Sample HTML Form

<!DOCTYPE html>
<html>
	<head>
		<title>Merchant Checkout</title>
	</head>
	<body>
		<form name="card form" action="https://www.computop-paygate.com/payNow.aspx" method="post">
			<input type="hidden" name="MerchantID" value="MerchantID">
			<input type="hidden" name="Len" value="Length of the Blowfish encrypted data">
			<input type="hidden" name="Data" value="Blowfish encrypted data">
			Cardholder:
			<input type="text" name="cardholder"><br> 
			Card number:
			<input type="text" name="number"><br>
			Expiry date:
			<input type="text" name="expiryDate"><br>
			CVV2:
			<input type="text" name="securityCode"><br>
			Card brand:
			<input type="text" name="brand"><br>
			<input type="submit" value="Submit">
		</form>
	</body>
</html>


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
1

MID

ans..30

M

Merchant identifier assigned by Computop.

2

MsgVer

ans..5

M

Message version.

Accepted values:

  • 2.0

3

PayID

ans32

M

Payment/transaction identifier assigned by Computop.

4

XID

ans64

M

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

5

TransID

ans..64

M

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

6

schemeReferenceID

ans..64

C

Card scheme specific transaction ID required for subsequent credential-on-file payments, delayed authorizations and resubmssions.

7

Status

a..20

M

Staus of the transaction.

Values accepted:

  • Authorized

  • OK (Sale)

  • FAILED

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

8

Description

ans..1024

M

Textual description of the code.

9

Code

n8

M

Paygate response code.

10

card

JSON

M

Card response data.

11

ipInfo

JSON

C

Object containing IP information. Presence depends on the configuration for the merchant.

12

threeDSData

JSON

M

Authentication data.

13

resultsResponse

JSON

C

In case the authentication process included a cardholder challenge additional information about the challenge result will be provided.

14

UserData

ans..1024

C

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

15

MAC

an64

M

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