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

MerchantID

--

Merchant identifier assigned by Computop

Len

--

The length of the original encrypted with Blowfish

Data

--

Blowfish encrypted data

number

CCNr

Card number

securityCode

CCCVC

Card security value

expiryDate

CCExpiry

Card expiry in format YYYYMM

brand

CCBrand

Card network

cardholder

CreditCardHolder

Name of the cardholder as printed on the card.

Notice: Alphanumeric special characters, listed in EMV Book 4, “Appendix B”. Special characters have been added with EMV 3DS Version 2.3, but not all participants (banks) already support that standard.


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

Data

KeyFormatCNDDescription

MerchantID

ans..30

M

MerchantID, assigned by Computop. Additionally this parameter has to be passed in plain language too.

KeyFormatCNDDescription
TransID

ans..64

MTransactionID provided by you which should be unique for each payment

KeyFormatCNDDescription

MsgVer

ans..5

M

Message version.

Accepted values:

  • 2.0

RefNr


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.

(info) Details on supported format can be found below in payment specific section.

Only ASCII characters allowed, special characters ("Umlaute", diacritics) are not allowed and must be replaced by their ASCII-representation (e.g. ü → ue, é → e, ...).

KeyFormatCNDDescription
Amountn..10M

Amount in the smallest currency unit (e.g. EUR Cent). Please contact the Computop Helpdesk, if you want to capture amounts <100 (smallest currency unit).

KeyFormatCNDDescription
Currency

a3

M

Currency, three letters DIN / ISO 4217, e.g. EUR, USD, GBP. Please find an overview here: A1 Currency table

KeyFormatCNDDescription
Capturean..6OM

Determines the type and time of capture.

Capture ModeDescription
AUTOCapturing immediately after authorisation (default value).
MANUALCapturing made by the merchant. Capture is normally initiated at time of delivery.
<Number>Delay in hours until the capture (whole number; 1 to 696).

KeyFormatCNDDescription

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.

OrderDesc

ans..768

O

Order description

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

threeDSPolicy

JSON

O

Object specifying authentication policies and excemption handling strategies

priorAuthenticationInfo

JSON

O

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

browserInfo

JSON

M

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

accountInfo

JSON

O

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

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.

shipToCustomer

JSON

C

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

billingAddress

JSON

C

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

shippingAddress

JSON

C

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

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.

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.

KeyFormatCNDDescription
URLSuccess

ans..256

M

Complete URL which calls up Platform if 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 Platform and shop, please use the parameter UserData.

(info) Common notes:

  • We recommend to use parameter "response=encrypt" to get an encrypted response by Platform
  • However, fraudster may just copy the encrypted DATA-element which are sent to URLFailure and send the DATA to URLSuccess. Therefore ensure to check the "code"-value which indicates success/failure of the action. Only a result of "code=00000000" should be considered successful.

KeyFormatCNDDescription
URLFailure

ans..256

M

Complete URL which calls up 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 Platform and shop, please use the parameter UserData.

(info) Common notes:

  • We recommend to use parameter "response=encrypt" to get an encrypted response by Platform
  • However, fraudster may just copy the encrypted DATA-element which are sent to URLFailure and send the DATA to URLSuccess/URLNotify. Therefore ensure to check the "code"-value which indicates success/failure of the action. Only a result of "code=00000000" should be considered successful.

KeyFormatCNDDescription
URLNotify

ans..256

M

Complete URL which 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.

(info) Common notes:

  • Before follow-up actions (capture / credit / reversal) are carried out on an existing transaction, the first Notify must have been answered by the shop.
  • Fraudster may just copy the encrypted DATA-element which are sent to URLFailure and send the DATA to URLSuccess/URLNotify. Therefore ensure to check the "code"-value which indicates success/failure of the action. Only a result of "code=00000000" should be considered successful.

KeyFormatCNDDescription

MAC

an64

M
Hash Message Authentication Code (HMAC) with SHA-256 algorithm. Details can be found here:

KeyFormatCNDDescription
UserData

ans..1024

O

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

Sample HTML Form

(info) BASEURL= https://www.computop-paygate.com/

<!DOCTYPE html>
<html>
	<head>
		<title>Merchant Checkout</title>
	</head>
	<body>
		<form name="card form" action="BASEURLpayNow.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 respectively 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

KeyFormatCNDDescription

mid

ans..30

M

MerchantID, assigned by Computop

KeyFormatCNDDescription
msgver

ans..5

M

Computop Paygate Message version. Valid values:

ValueDescription
2.0With 3-D Secure 2.x a lot of additional data were required (e.g. browser-information, billing/shipping-address, account-info, ...) to improve authentication processing. To handle these information the JSON-objects have been put in place to handle such data. To indicate that these data are used the MsgVer has been implemented.

KeyFormatCNDDescription
PayID

an32

M

ID assigned by Platform for the payment, e.g. for referencing in batch files as well as for capture or credit request.

KeyFormatCNDDescription
XID

an32

M

ID for all single transactions (authorisation, capture, credit note) for one payment assigned by Platform

KeyFormatCNDDescription
TransID

ans..64

MTransactionID provided by you which should be unique for each payment

KeyFormatCNDDescription
schemeReferenceID

ans..64

C

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

Mandatory: CredentialOnFile – initial false – unscheduled MIT / recurring

schemeReferenceID is returned for 3DS2-payments. In case of fallback to 3DS1 you will also need to check for TransactionId.

The schemeReferenceID is a unique identifier generated by the card brands and as a rule Computop merchants can continue to use the SchemeReferenceIDs for subscription plans that were created while using another PSP environment / Platform MerchantID / Acquirer ContractID / Acquirer.

KeyFormatCNDDescription
refnr
OReference number taken from request

Status

a..20

M

Status of the transaction.

Values accepted:

  • Authorized

  • OK (Sale)

  • FAILED

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

KeyFormatCNDDescription
Description

ans..1024

M
Further details in the event that payment is rejected. Please do not use the Description but the Code parameter for the transaction status analysis!

KeyFormatCNDDescription
Code

an8

M

Error code according to Platform Response Codes (A4 Error codes)

KeyFormatCNDDescription

card

JSON

M

Card response data

ipinfo

JSON

C

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

threedsdata

JSON

M

Authentication data

resultsresponse

JSON

C

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

externalPaymentDataJSONOOptional additional data from acquirer/issuer/3rd party for authorization

KeyFormatCNDDescription
UserData

ans..1024

O

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

KeyFormatCNDDescription

MAC

an64

M
Hash Message Authentication Code (HMAC) with SHA-256 algorithm. Details can be found here: