First Cash Solution’s the 1cs Online Payment System processes all major cards and currencies worldwide. Card data is protected against unauthorised access by TLS encryption. Additional security functions are integrated fraud prevention and risk management. Our standardized settlement files guarantee a straightforward reconciliation processes in your accounting.

Visa Secure and MasterCard SecureCode secure your payment claim by password validation if a customer disputes the payment later. American Express SafeKey also uses the 3-D Secure technology, which means that the card holder must confirm their identity with a password.

Transaction processing can be made via the 1cs Online Payment System standard form, via customized forms, via server-to-server-connection or via batch transfer. Likewise the 1cs Online Payment System can process transactions from stationary terminals.

Using the card form provides several advantages:

Merchants can bypass the costly PCI-security authorisation
The programming of 3-D Secure with forms is much easier and quicker than via Server-to-Server connection

Info	Type
The 1cs Online Payment System processes all major cards and currencies worldwide. Transaction processing can be made via 1cs Online Payment System standard form, via customized forms, via server-to-server-connection or via batch transfer. Likewise the 1cs Online Payment System can process transactions from stationary terminals.	Payments by Credit Card

1.2 Process of 3-D Secure payments

MasterCard SecureCode (UCAF), Visa Secure, Diners ProtectBuy, JCB J/Secure and American Express SafeKey are authentication methods which verify the identity of the card holder before making the payment. The name 3-D Secure used by technicians describes only the protocol. The correct brand names are Verified by Visa, MasterCard SecureCode, SafeKey, ProtectBuy and J/Secure.

Merchants benefit from authentication with 3-D Secure because the card schemes provide a liability shift: If you are using Visa Secure, MasterCard SecureCode, Diners ProtectBuy, JCB-Card J/Secure or American Express SafeKey, the burdon of proof and thereby generally the liability is shifted from the merchant to the card issuing bank, should the customer dispute the payment. Irrespective of whether the card holder actually uses the authentication you obtain a very high protection against payment defaults / chargebacks in case the customer states they have not authorised the card payment. Your Acquirer will be able to discuss the details of 3-D Secure and the cover that it provides.

From a technical perspective 3-D Secure is not a payment method but an authentication process which precedes the payment: Once the credit card data has been entered, the 1cs Online Payment System checks the identity of the card holder and does not process the payment until after the authentication.

For further steps it is crucial if the credit card connection is made via form interface or via Server-to-Server-connection. In the first case the 1cs Online Payment System form assumes the further authentication process, with Server-to-Server-connection the merchant has to manage the authentication through a separate interface.

Notice: Please make sure to review our EMV 3D Secure Specification to integrate according to the newest standards.

Notice: Please notice that in case of Fallback to 3-D Secure 1.0 the URLSuccess or URLFailure is called with GET. Therefore your systems should be able to receive parameters both via GET and via POST.

1.2.1 Process of a transaction with 3-D Secure via form interface

When requesting card payments via 1cs Online Payment System 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.

Simplified Sequence Diagram

When requesting card payments via the 1cs Online Payment System hosted forms the complexity of 3-D Secure is completely removed from the merchant implementation.

Notice about Cookie-/Session Handling: Please note that some browsers might block necessary cookies when returning to Your shop. Here you will find additional information and different solution approaches.

The 1cs Online Payment System 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 card holder to.

Card holder authentication and payment authorization will take place once the the cardholder entered all required card details and submitted the form data to the 1cs Online Payment System.

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 the 1cs Online Payment System 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 receive parameters both via GET and via POST.

The credit card form can be highly customized by using your own template.

Details are available here: Corporate PayPage and templates

If the password is correct the 1cs Online Payment System obtains confirmation in the form of a signature. Only after confirmation does the 1cs Online Payment System start the payment and send the transaction with the signature to the Acquiring Bank.

Details on the integration can be found here: Credit Card Form (paySSL)

1.2.2 Process of a transaction with 3-D Secure via Server-to-Server-connection

A 3-D Secure 2.0 payment sequence may comprise the following distinct activities:

Versioning: Request ACS and DS Protocol Version(s) that correspond to card account range as well as an optional 3-D Secure Method URL
3-D Secure Method: Connect the cardholder browser to the issuer ACS to obtain additional browser data
Authentication: Submit authentication request to the issuer ACS
Challenge: Challenge the card holder if mandated
Authorization: Authorize the authenticated transaction with the acquirer

Please note that the the communication between client and Access Control Server (ACS) is implemented through iframes. Thus, responses arrive in an HTML subdocument and you may establish correspondent event listeners in your root document.

Alternatively you could solely rely on asynchronous notifications delivered to your backend. In those cases you may have to consider methods such as long polling, SSE or websockets to update the client.

The initial request to the 1cs Online Payment System will be the same regardless of the underlying 3-D Secure Protocol.

In order to start a server-to-server 3-D Secure card payment sequence please post the following key-value-pairs to https://www.computop-paygate.com/ direct.aspx.

Parameter	Format	CND	Description
ACSURL	ans..	C	Only in the case of registered credit cards: URL of the Access Control Server of the card issuer with attached request parameters (not URL-encoded!). It is possible to use ACS server ampersand and question mark as value within the URL; everything before parameter PAReq is part of ACSURL.
PaReq	ans..	M	Payer Authentication Request, which must be URL-encoded.
MD		M	Merchant Data is an empty value, which must be transferred for compatibility reasons
TermURL	ans..	M	Shop return address. the 1cs Online Payment System adds the parameters PayID, TransID and MID as request parameters to the initial TermURL seperated with a question mark.

1.3 Credit card brands

1.3.1 Overview of supported card schemes by payment method

Card processing

The 1cs Online Payment System processes all major cards and currencies worldwide. Transaction processing can be made via the 1cs Online Payment System standard form, via customized forms, via server-to-server-connection or via batch transfer. Likewise the 1cs Online Payment System can process transactions from stationary terminals.

Credit card brand, correct spelling for CCBrand

MasterCard

VISA

AMEX

DINERS

CBN

JCB

Dankort

Maestro

Cartes Bancaires

Discover

Bancontact

Hipercard

Elo

Aura

Carte 4Etoiles

AirPlus

CUP

NARANJA

SHOPPING

CABAL

ARGENCARD

CENCOSUD

KOOKMIN

KEB

SHINHAN

SAMSUNG

HYUNDAI

LOTTE

1euro

echequevacances

cofidis3xcb

cofidis4xcb

facilypay-3x

facilypay-3xsansfrais

facilypay-4x

facilypay-4xsansfrais

RuPay

Bancontact

Bancontact is a Belgian payment method for Debit cards with which the merchant obtains a payment guarantee and eliminates the risk of chargebacks. At the Bancontact checkout customers enter their card details and are then directed to their own online bank where they simply need to authorize the payment they have just made.

Card Scheme

Bancontact

Be2Bill

Be2bill is specially optimized for the “Cartes Bancaires” credit cards which is widely used in France.

Card Scheme

VISA

MasterCard

Cartes Bancaires

Cofidis

The 4-star card is a private card that combines payment facilities and loyalty benefits. The design of tailor-made products and services has been adapted to customers, expectations and needs. Pay for your purchases in several instalments. The 4-star card is a revolving credit card that offers you the possibility, depending on the amount of your purchases and the brand, to pay in several instalments.

Card Scheme

Carte 4Etoiles

cofidis3xcb

cofidis4xcb

facilypay-3x

fayilypay-3xsansfrais

facilypay-4x

facilypay-4xsansfrais

Korea CC

KoreaCC is a payment method which enables Korean merchants (based in South Korea) to offer domestic customers (with Korean credit cards) a credit card payment method.

Card Scheme

MasterCard

VISA

AMEX

JCB

KOOKMIN

KEB

SHINHAN

SAMSUNG

HYUNDAI

LOTTE

MasaPay

Shanghai MasaPay Information Technology Co., Ltd. is a third-party transnational e-payment service provider which was established in July 2012. Her headquarter is based in Lujiazui Financial Service District, Shanghai, China.

MasaPay offers an Online Payment Gateway, which supports credit card payment of Visa, MasterCard, JCB, AMEX, Discover, Diners etc. MasaPay makes it possible that the cross-border payments from outside China are acquired in China.

Card Scheme

MasterCard

VISA

AMEX

Diners

Discover

JCB

PagBrasil

Payments with the Brazilian credit cards Hipercard, Elo and Aura can be processed via the 1cs Online Payment System. The 1cs Online Payment Systemoffers extensive support for the control optimisation as well as foreign currency conversion.

More than 30% of online payments in Brazil are made using the Boleto Bancário cash-in solution. With a payment form customers can pay in cash in supermarkets, post office branches or at one of over 48,000 bank terminals.

PIX via PagBrasil is now also supported.

Card Scheme

VISA

MasterCard

AMEX

Dines

Elo

Aura

Hipercard

PayU India

With the integration of PayU biz India merchants open the door to a rapidly growing e-commerce market. Only 30% of online customers in India have access to internationally accepted payment methods. With the integration of PayU biz via the 1cs OPS merchants can offer 76 local payment methods to serve the majority of customers. This comprises of online transfers, credit and debit cards, eWallets and cash-in payments.

Card Scheme

MasterCard

VISA

AMEX

Diners

RuPay

PayU LatAm

Within the extremely heterogeneous e-commerce market of Latin America success depends on offering the requested payment methods. The integration of PayU gives the merchant access to 74 payment methods from Mexico to Argentina. Besides all major online transfers as well as credit and debit cards PayU also offers payments with modern e-wallets and popular cash-in-payments.

Card Scheme

MasterCard

VISA

AMEX

Diners

Hipercard

Elo

NARANJA

SHOPPING

CABAL

ARGENDCARD

CENCOSUD

2 Card processing – common form

2.1 Card processing – Credit Card Form

When requesting card payments via the 1cs Online Payment System hosted forms the complexity of 3-D Secure is completely removed from the merchant implementation.

2.1.1 Simplified Sequence Diagram

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

2.1.2 Payment Request

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

Notice: For security reasons, the 1cs OPS rejects all payment requests with formatting errors. Therefore, please use the correct data type for each parameter.

The following table describes the encrypted payment request parameters:

Paramter	Format	CND	Bescheribung
MerchantID	ans..30	M	MerchantID, assigned by the 1cs OPS. Additionally this parameter has to be passed in plain language too.
MsgVer	ans..5	M	Message version. Valid values: Value: 2.0 Description: With 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.
ReqID	ans..32	O	To avoid double payments or actions (e.g. by ETM), enter an alphanumeric value which identifies your transaction and may be assigned only once. If the transaction or action is submitted again with the same ReqID, the 1cs Online Payment System will not carry out the payment or new action, but will just return the status of the original transaction or action. Please note that the 1cs Online Payment System must have a finalized transaction status for the first initial action (authentication/authorisation). This does not apply to 3-D Secure authentications that are terminated by a timeout. The 3-D Secure Timeout status does not count as a completed status in which the ReqID functionality on the 1cs Online Payment System does not take effect. Submissions with identical ReqID for an open status will be processed regularly. Notice: Please note that a ReqID is only valid for 12 month, then it gets deleted at the 1cs Online Payment System.
TransID	ans..64	M	TransactionID provided by you which should be unique for each payment
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 the 1cs Online Payment System settlement file (CTSF) we cannot add the additional payment data. 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, …).
MAC	an64	M	Hash Message Authentication Code (HMAC) with SHA-256 algorithm. Details can be found here: HMAC Authentication (Request) HMAC Authentication (Notify)
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 DIN / ISO 4217, e.g. EUR, USD, GBP. Please find an overview here: Currency table
Capture	an..6	OM	Determines the type and time of capture. AUTO: Capturing immediately after authorisation (default value). MANUAL: Capturing made by the merchant. Capture is normally initiated at time of delivery. <Number>: Delay in hours until the capture (whole number; 1 to 696).
PayTypes	ans..256	O	With this parameter you can override the accepted schemes, i.e. you can decide within this parameter separated by pipe which of the available credit card schemes are displayed. The template must support this function like for example the “Cards_v1”. Example: PayTypes=VISA\|MasterCard
BillingDescriptor	ans..22	O	A descriptor to be printed on a card holder’s statement. Please also refer to the additional comments made elsewhere 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 exemption handling strategies
PriorAuthenticationInfo	JSON	O	Prior Transaction Authentication Information contains optional information about a 3DS cardholder authentication that occurred prior to the current transaction
AccountInfo	JSON	O	The account information contains optional information about the customer account with the merchant
BillingToCustomer	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.
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 for EMV 3DS (if available) unless market or regional mandate restricts sending this information.
ShippingAddress	JSON	C	Shipping address. If different from billingAddress, required for EMV 3DS (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.
SubMerchantPF	JSON	O	Object specifying SubMerchant (Payment Facilitator) details. Only supported by SafeCharge
URLSuccess	ans..256	M	Complete URL which calls up the 1cs Online Payment System 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 the 1cs Online Payment System and shop, please use the parameter UserData. Common notes: We recommend to use parameter “response=encrypt” to get an encrypted response by the 1cs Online Payment System 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.
URLFailure	ans..256	M	Complete URL which calls up the 1cs OPS 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 1cs OPS and shop, please use the parameter UserData. Common notes: We recommend to use parameter “response=encrypt” to get an encrypted response by the 1cs Online Payment System 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.
URLBack	ans..256	O	Complete URL which the 1cs Online Payment System calls in case that Cancel is clicked by the customer. The parameter “URLBack” can be sent either as plain parameter (unencrypted) (compatibility mode) or be part of encrypted payment request parameters (preferred mode) In order to exchange values between the 1cs Online Payment System and shop you may use something like this: URLBack=https://your.shop.com/back.php?param1%3Dvalue1%26param2%3Dvalue3%26status%3Dcancelled When user cancels payment this URL is called exactly like this and you may use URL Decode to extract parameter and values.
Response	a7	O	Status response sent by the 1cs OPS to URLSuccess and URLFailure, should be encrypted. For this purpose, transmit Response=encrypt parameter.
URLNotify	ans..256	M	Complete URL which the 1cs Online Payment System 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. Common notes: We recommend to use parameter “response=encrypt” to get an encrypted response by the 1cs Online Payment System 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.
UserData	ans..1024	O	If specified at request, the 1cs OPS forwards the parameter with the payment result to the shop.
Custom	ans..1024	O	“Custom”-parameter is added to the request data before encryption and is part of encrypted “Data” in the 1cs OPS request. By this they are protected against manipulation by a consumer. The Custom-value is added to the1cs Online Payment System response in plain text and the “\|” is replaced by a “&”. By this you can put a single value into Custom-parameter and get multiple key-value-pairs back in response for your own purpose.
Plain	ans..50	O	A single value to be set by the merchant to return some information unencrypted in response/notify, e.g. the MID. “Plain”-parameter is part of encrypted “Data” in 1cs Online Payment System and therefore protected against manipulation.
ExpirationTime	ans..19	O	Timestamp for the end time of the transaction processing, specified in UTC. Format: YYYY-MM-ddTHH:mm:ss

Card holder authentication and payment authorization will take place once the the cardholder entered all required card details and submitted the form data to the 1cs Online Payment System.

When the payment is completed the 1cs Online Payment Systeme 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.

The credit card form can be highly customized by using your own template.

Details are available here: Corporate PayPage and templates

2.1.3 HTTP POST to URLSuccess / URLFailure / URLNotify

The following table gives the result parameters which the 1cs Online Payment System transmits to URLSuccess or URLFailure and URLNotify. If you have specified the Response=encrypt parameter, the following parameters are sent Blowfish encrypted to your system:

be prepared to receive additional parameters at any time and do not check the order of parameters

the parameters (e.g. MerchantId, RefNr) should not be checked case-sentive

Parameter	Format	CND	Beschreibung
MID	ans..30	M	MerchantID, assigned by the 1cs Online Payment System
MsgVer	ans..5	M	Valid Values: Wert: 2.0 Description: With 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.
PayID	an32	M	ID assigned by the 1cs Online Payment System for the payment, e.g. for referencing in batch files as well as for capture or credit request.
XID	an32	M	ID for all single transactions (authorisation, capture, credit note) for one payment assigned by the 1cs Online Payment System
TransID	ans..64	M	TransactionID provided by you which should be unique for each payment
SchemaReferenceID	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 the 1cs Online Payment System merchants can continue to use the SchemeReferenceIDs for subscription plans that were created while using another PSP environment / Paygate MerchantID / Acquirer ContractID / Acquirer.
RefNR		O	Reference 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.
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!
Code	n8	M	Error code according to Paygate Response Codes (A4 Error codes)
Card	JSON	M	Card data
IpInfo	JSON	O	Object containing IP informationen
ThreeDsData	JSON	M	Authentisierung data
ResultResponse	JSON	C	In case the authentication process included a cardholder challenge additional information about the challenge result will be provided.
ExternalPaymentData	JSON	O	Optional additional data from acquirer/issuer/3rd party for authorization.
TimeStamp	Date/Time	O	Timestamp of this action if activated by Helpdesk, e.g. 30.05.2023 08:47:57 or 30.05.2023 10:03:01.633
CardHolder	ans..50	O	Card holder name if activated by Helpdesk, e.g. John Doe
bin	n..6	O	BIN of credit card if activated by Helpdesk, e.g. 40001
maskedpan	an..19	O	Masked number of credit card if activated by Helpdesk, e.g. 400001XXXXXX8323
cardinfo	JSON	O	JSON containing data of credit card type and issuer if activated by Helpdesk, e.g. {“BIN”:”400001″,”Brand”:”VISA”,”Product”:””,”Source”:”CREDIT”,”Type”:””,”Country”:{“A3″:”USA”,”N3″:”840″},”Issuer”:””}
CCBrand	an..20	O	Brand / card scheme of credit card, e.g. VISA
PCNr	n16	O	Pseudo Card Number: Random number generated by the 1cs OPS which represents a genuine credit card number. The pseudo card number (PCN) starts with 0 and the last 3 digits correspond to those of the real card number. The PCN can be used like a genuine card number for authorisation, capture and credits. PCNr is a response value from the 1cs OPS and is sent as CCNr in Request or part of card-JSON
CCExpiry	n6	OC	Optional in combination with PCNr: Expiry date of the credit card in the format YYYYMM (202207).
Plain	ans..50	O	Single value to be set by the merchant to return some information unencrypted in response/notify, e.g. the MID. “Plain”-parameter is part of encrypted “Data” in the 1cs OPS and therefore protected against manipulation.
Custom	ans..1024	O	“Custom”-parameter is added to the request data before encryption and is part of encrypted “Data” in the 1cs Online Payment System request. By this they are protected against manipulation by a consumer. The Custom-value is added to the 1cs OPS response in plain text and the “\|” is replaced by a “&”. By this you can put a single value into Custom-parameter and get multiple key-value-pairs back in response for your own purpose.
UserData	ans..1024	O	If specified at request, 1cs Online Payment System forwards the parameter with the payment result to the shop.
MAC	an64	M	Hash Message Authentication Code (HMAC) with SHA-256 algorithm. Details can be found here: HMAC-Authentisierung (Request) HMAC-Authentisierung (Notify)

2.1.4 Credit card payments with separate authorisation

For credit card payments the ORDER can be separated from the subsequent authorisation and the following steps. Therefore initially the SSL credit card payment is initiated via the 1cs OPS form or via Server-to-Server-connection like in the chapters above with an additional parameter. Later it is authorised using the interface authorize.aspx via server-to-server connection. For initialising visit the following URL:

https://www.computop-paygate.com/payssl.aspx

For Server-to-Server-connection it is the following URL:

https://www.computop-paygate.com/direct.aspx

The following table describes the encrypted payment request parameters:

Key	Format	CND	Description
TxType	ans..20	M	Submit “Order” to initialize a payment which later will be authorised via interface authorize.aspx. Please note that in combination with the used 3-D Secure method a separate setting is necessary. Please contact directly 1cs Helpdesk.

Additional parameters for credit card payments with separate authorisation

In order to authorise a previously with TxType=Order initiated SSL credit card payment, please visit the following URL:

https://www.computop-paygate.com/authorize.aspx

Notice: Please note, that for an initial order KPN/CVC/CVV-check is not possible. For the subsequent reservation request this ID also cannot be passed on.

Notice: For security reasons, the 1cs OPS rejects all payment requests with formatting errors. Therefore, please use the correct data type for each parameter.

The following table describes the encrypted payment request parameters:

Parameters for credit card payments via authorize.aspx

The following table describes the result parameters with which the 1cs online payment system responds to your system

be prepared to receive additional parameters at any time and do not check the order of parameters

the parameters (e.g. MerchantId, RefNr) should not be checked case-sentive

Key	Format	CND	Description
MerchantID	ans..30	M	MerchantID, assigned by the 1cs Online Payment System. Additionally this parameter has to be passed in plain language too.
PayID	an32	M	ID assigned by the 1cs Online Payment System for the payment, e.g. for referencing in batch files as well as for capture or credit request.
TransID	ans..64	M	TransactionID provided by you which should be unique for each payment
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 DIN / ISO 4217, e.g. EUR, USD, GBP. Please find an overview here: Currency table
OrderDesc	ans..768	O	Description of purchased goods, unit prices etc.
MAC	an64	M	Hash Message Authentication Code (HMAC) with SHA-256 algorithm. Details can be found here: HMAC Authentication (Request) HMAC Authentication (Notify)
Capture	an..6	M	Determines the type and time of capture. AUTO: Capturing immediately after authorisation (default value). MANUAL: Capturing made by the merchant. Capture is normally initiated at time of delivery. <Number>: Delay in hours until the capture (whole number; 1 to 696).

Key	Format	CND	Description
MID	ans..30	M	MerchantID, assigned by the 1cs Online Payment System
PayID	an32	M	ID assigned by the 1cs Online Payment System for the payment, e.g. for referencing in batch files as well as for capture or credit request.
XID	an32	M	ID for all single transactions (authorisation, capture, credit note) for one payment assigned by the 1cs Online Payment System
Code	n8	M	Error code according to Paygate Response Codes (A4 Error codes)
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!
TransID	ans..64	M	TransactionID provided by you which should be unique for each payment
Status	a..50	M	AUTHORIZED or FAILED
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 the 1cs Online Payment System settlement file (CTSF) we cannot add the additional payment data. 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, …).

Ergebnis-Parameter für Kreditkartenzahlungen über authorize.aspx

2.1.5 Erweitertes Sequenz-Diagramm

2.2 Corporate PayPage

The 1cs Online Payment System forms are framed as standard in white and grey. Merchants can customise the layout of the forms with the help of layout parameters. The simplest way to change the layout is to set the parameters for the background colour (BGColor), background image (BGImage) and the font (FFace). You can use XSL-templates to change the layout further:

In the case of credit card payments you can change the parameter Template to create an individual layout for your PaySSL form which exactly matches the shop layout. To this end your graphic designer can design an HTML-template in the shop-design based on XSLT (Extensible Stylesheet Language Transformation). First Cash Solution Support copies this XSLT-template to our the 1cs Online Payment System Server. If you enter the name of your XSLT-file in the Template parameter, the 1cs Online Payment System form will appear in your layout.

For general information about XSLT see www.w3.org.

Please note, that the 1cs OPS is a fee-based additional service. Please ask 1cs OPS Sales thereun.

1cs OPS provides a programming example for creating a responsive credit card form online at https://www.computop.com/de/xslt. The template files to be created – XSL and XML – afterwards are transformed automatically for the various browsers. Please ensure before sending to the 1cs Online Payment System that both files can be loaded into the browser correctly. The complete code must be able to be displayed and no error message are allowed. If an error message occurs the code and used tags have to be revised. Please note that new versions must be available not later then 3:30 pm in order to to be processed on the same day.

The subsequent conventions apply for the use of the Corporate Paypage with XSLT:

2.2.1 File names

A XSL file designed by you defines your individual layout. The associated XML file contains the texts that are to be displayed on the form. Hence, multilingualism is easy. Always use your MerchantID in the names of the files.

XSL template:                   MerchantID_PaySSL.xsl
XML text file:                  MerchantID_PaySSL.xml
Sub-folder for images:   Templates/imagesMerchantID

In order not to receive safety notices, please ensure that external image sources are retrieved via SSL.

In order to call the individual layout, use the ‘template’ parameter with your MerchantID and attach it unencrypted to the call of the First Cash Solution payment page, for example: https://www.computop-paygate.com/payssl.aspx?MerchantID=IhreMID&Len=123&Data=AGSDJ…ASDF&template=IhreMerchantID

2.2.2 Field names of the form

When implementing the text field for the credit card number, use the following values for the parameters ‘name’ and ‘id’:

Year of expiry:                          „cardExpirationYear“
Expiry date month:                 „cardExpirationMonth“
Credit card number:               „cardNumber“
Card verification number:      „cccvc“
Card brand:                          „ccBrand“

A text field for the input of the credit card number is then implemented as follows:

2.2.3 Hidden Fields

The following hidden fields must be implemented so that the values can be passed on when sending the form:

ID	Value	Notes
MerchantID	MerchantID	MerchantId assigned by the 1cs Online Payment System
Len	Request length	Length of unencrypted (!) data before encryption
Data	Request Data	Encrypted data
Template	Template	Template name
Counter	Repeat attempts
Language	Language
Notify	Notify	optional in the case of repeat attempts
AddrChoice	Address choice	Only with American Express Adress Verification Service

2.2.4 Language selection

The language selection in form PaySSL.aspx is automatically based on the parameterLanguage. Other language areas are filtered out. If you wish to access the field of another language area e.g. with JavaScript, you can do so via the following path: paygate/language/@name.

2.2.5 XML structure

The ‘language’ parameter controls which section of the XML text file is read out. German ‘de’ is always used as standard.

The XML file should have the following basic structure:

<?xml version="1.0" encoding="windows-1252"?>

</languages> <language name="de"> </language> <language name="en"> </language> </languages>

‘UTF-8’ is also possible for the encoding.

With <xsl:variablename=““ select=“paygate/language/@name”/> you can directly address an XML language section from the XSL file.

For an overview of which parameters are additionally rendered by the PaySSL, please examine the following structure (XSL file is rendered against the following XML string):

strXML = “<?xml version=’1.0′ encoding=’windows-1252′?>” & _

“<paygate pay=’ssl’>” & _

“<merchantID>”…”</merchantID>” & _

“<len>”…”</len>” & _

“<data>”…”</data>” & _

“<Background>”…”</Background>” & _

“<BGImage>”…”</BGImage>” & _

“<BGColor>”…”</BGColor>” & _

“<FFace>”…”</FFace>” & _

“<FSize>”…”</FSize>” & _

“<FColor>”…”</FColor>” & _

“<center>”…”</center>” & _

“<CCard>”…”</CCard>” & _

“<Year>”…”</Year>” & _

“<URLBack>”…”</URLBack>” & _

“<twidth>”…”</twidth>” & _

“<theight>”…”</theight>” & _

“<brands><brand>”…”</brand></brands>” &_

“<cvc>”…”</cvc>” &_

“<ccexpiryyear>” … “</ccexpiryyear>” & _

“<ccbrand>” … “</ccbrand>” & _

“<template>”…”</template>” & _

“<counter>”… “</counter>” & _

“<notify>”… “</notify>” & _

“<errorcode>”…”</errorcode>” & _

“<PCNr>”…”</PCNr>” & _

“<PCNrBrand>”… “</PCNrBrand>” & _

“<PCNrMonth>”… “</PCNrMonth>” & _

“<PCNrYear>”… “</PCNrYear>” & _

“<creditcardholder>” … “</creditcardholder>” & _

“<Autostart>”…”</Autostart>” & _

<language/@name … (Area for selected language-Node)

(content of MerchantId_PaySSL.xml in the respective language)>

“</paygate>”

Since merchants use its own layout for the form, you do not require the layout parameter. However, it is possible after prior consultation with First Cash Solution to use the parameters for the transfer, e.g. the SessionID.

2.2.6 Error mapping

In the case of the error codes listed below First Cash Solution returns the form in order to enable the credit card data to be entered again. You only have to evaluate the ‘error code’ parameter and display the desired text from your XML file.

At this point the ‘error code’ template is called:

<xsl:apply-templates select=“/paygate/errorcode” />

The called-up ‘error code’ template may look like this. It can alternatively be implemented with ‘if’.

<xsl:template match="errorcode">

<tr> <td> <xsl:choose> <xsl:when test=".='0015'"> <xsl:value-of select="/paygate/language/ErrorCodeDescription/Description1"/>  </xsl:when> ... </xsl:choose> </td> </tr> </xsl:template>

It is also possible to integrate the error messages directly into the (main) template:

<xsl:if test="paygate/errorcode != ''">

<xsl:choose> <xsl:when test="paygate/errorcode='0015'"> <xsl:value-of select="/paygate/language/ErrorCodeDescription/Description1"/>  </xsl:when> </xsl:choose> </xsl:if>

2.2.7 JavaScript

If JavaScript functions are desired, you must implement them in your template.

<script id=“clientEventHandlersJS“ language=“JavaScript“>

if (document.SSLForm.cardNumber.value.length> 19)

{

alert(„<xsl:value-of select=“/paygate/language/strJavaScript1“/>“);

document.SSLForm.cardNumber.focus();

}

...

</script>

Please do not use any external link to your JavaScript.

2.2.8 Link to Visa Secure and MasterCard Secure Code

Visa and MasterCard regulations require that your pay page displays the Visa Secure and SecureCode logo. Please link the Verified logo to https://www.computop-paygate.com/vbv.aspx and the SecureCode logo to https://brand.mastercard.com/brandcenter/mastercard-brand-mark/downloads.html.

2.2.9 Programming and testing the form

First design a HTML page with the layout for your payment page and initially save it for testing with the file extension .htm or .html. Open this file in the browser. Next, save this as an xsl file.

<?xml version="1.0" encoding="windows-1252"?>

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

<xsl:output method="html" encoding="UTF-8"/>

<xsl:template match="/">

<html>

<head>

<title>PaySSL Template</title>

<script>Your JavaScript</script>

</head>

<body>

<form action="https://www.computop-paygate.com/payinterim.aspx" method="POST"> Your form with hidden fields and xsl-tags

</form>

</body>

</html>

</xsl:template>

In order to read the texts from the XML file, first of all create your tags in the desired language sections with the texts:

<language name="de">

<strCCNumber>credit card number</strCCNumber>

</language>

Subsequently, replace the text in the HTML by a reference to the respective section in the XML file:

<xsl:value-of select="/paygate/language/strCCNumber"/>

In order to test your template, we request that you integrate the following lines in your XML file only for the test (before sending it to First Cash Solution) and afterwards to call up the XML file in a browser. If no error is displayed you can send your template and the image folder in a Zip file to First Cash Solution’s Support with a request to check and install it.

<?xml version="1.0" encoding="windows-1252"?>

<?xml-stylesheet type="text/xsl" href="templatename.xsl"?>

<paygate>

<languages>please omit for your layout tests

<language name="de">

</language>

<language name="en">

</language>

<languages>please omit for your layout tests

</paygate>

In order to get an overview of the versions, please include the date and version number in the name of your Zip file.

As with the credit card form, it is now also possible to design your own XSLT templates for the SEPA direct debit form. In exactly the same way as with the credit card form, this is controlled via the ‘Template’ parameter. This can be called via the following URL:

https://www.computop-paygate.com/paySDD.aspx?MerchantID=IhreMID&Len=123&Data=AGSDJ…ASDF&template=YourMerchantID

The files must use the following naming convention:

XSL template: MerchantID_PaySDD.xsl

XML text file: MerchantID_PaySDD.xml

Sub-folder for images: Templates/imagesMerchantID

Notice: A Corporate Paypage offers you much more extended functions like for example a preconfiguration of card data which are not explained in detail here. For questions about extended functions please consult the 1cs Online Payment System Support.

3 Server-2-Server Sequence Diagramm

3.1 Card processing – Server-2-Server integration

A 3-D Secure 2.0 payment sequence may comprise the following distinct activities:

Versioning: Request ACS and DS Protocol Version(s) that correspond to card account range as well as an optional 3-D Secure Method URL
3-D Secure Method:Connect the cardholder browser to the issuer ACS to obtain additional browser data
Authentication: Submit authentication request to the issuer ACS
Challenge: Challenge the card holder if mandated
Authorization:Authorize the authenticated transaction with the acquirer

3.2 Server-2-Server Sequence Diagram

Please note that the the communication between client and Access Control Server (ACS) is implemented through iframes. Thus, responses arrive in an HTML subdocument and you may establish correspondent event listeners in your root document.

3.3 Payment Initiation

The initial request to the 1cs Online Payment System will be the same regardless of the underlying 3-D Secure Protocol.

In order to start a server-to-server 3-D Secure card payment sequence please post the following key-value-pairs to https://www.computop-paygate.com/ direct.aspx.

3.4 Call of interface: general parameters

Notice: For credit card payments with 3D Secure, please note the different cases as explained separately in the chapter at the start of the handbook. If the credit card is registered for Verified or SecureCode or SafeKey, the next phase is divided into two steps of authentication and payment. However it always begins in the same way via the direct.aspx interface. The first response however is the receipt of Javascript code or other parameters in order to carry out a second call up of the direct3d.aspx interface. Only after that, do you receive the listed parameter as a response.

To carry out a TLS credit card payment via a Server-to-Server connection, call the following URL:

https://www.computop-paygate.com/direct.aspx

3.4.1 Request Elements

Notice: For security reasons, the 1cs Online Payment System rejects all payment requests with formatting errors. Therefore, please use the correct data type for each parameter.

The following table describes the encrypted payment request parameters:

Notice: In case of a merchant initiated recurring transaction the JSON objects (besides credentialOnFile and card), the URLNotify and TermURL are not mandatory parameters, because no 3-D Secure and no risk evaluation is done by the card issuing bank and the payment result is directly returned within the response.

Parameter	Format	CND	Beschreibung
MerchantID	ans..30	M	MerchantID, assigned by 1cs Online Payment System. Additionally this parameter has to be passed in plain language too.
MsgVer	ans..5	M	Message version. Valid values: Value: 2.0 Description: With 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.
TransID	ans..64	M	TransactionID provided by you which should be unique for each payment
ReqID	ans..32	O	To avoid double payments or actions (e.g. by ETM), enter an alphanumeric value which identifies your transaction and may be assigned only once. If the transaction or action is submitted again with the same ReqID, 1cs OPS will not carry out the payment or new action, but will just return the status of the original transaction or action. Please note that the 1cs Online Payment System must have a finalized transaction status for the first initial action (authentication/authorisation). This does not apply to 3-D Secure authentications that are terminated by a timeout. The 3-D Secure Timeout status does not count as a completed status in which the ReqID functionality on the 1cs Online Payment System does not take effect. Submissions with identical ReqID for an open status will be processed regularly. Notice: Please note that a ReqID is only valid for 12 month, then it gets deleted at the 1cs Online Payment System .
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 1cs OPS settlement file (CTSF) we cannot add the additional payment data. 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, …).
SchemaReferenceID	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 the 1cs Online Payment System merchants can continue to use the SchemeReferenceIDs for subscription plans that were created while using another PSP environment / 1cs OPS MerchantID / Acquirer ContractID / Acquirer.
IndustrySpecificTxType	ans..10	C	This parameter is required whenever an industry specific transaction is processed according to the card brands MIT (Merchant Initiated Transactions) Framework, i.e.: specific use cases like described below. Only supported with Omnipay and GICC. Supported with CB2A for Reauthorization, only. Values: Resubmission: A merchant performs a re-submission in cases where it requested an authorization, but received a decline due to insufficient funds; however, the goods or services were already delivered to the cardholder. Merchants in such scenarios can resubmit the request to recover outstanding debt from cardholders. Reauthorization: A merchant initiates a re-authorization when the completion or fulfillment of the original order or service extends beyond the authorization validity limit set by Visa. There are two common re-authorization scenarios: • *Split or delayed shipments* at eCommerce retailers. A split shipment occurs when not all the goods ordered are available for shipment at the time of purchase. If the fulfillment of the goods takes place after the authorization validity limit set by Visa, eCommerce merchants perform a separate authorization to ensure that consumer funds are available. • Extended stay hotels, car rentals, and cruise lines. A re-authorization is used for stays, voyages, and/or rentals that extend beyond the authorization validity period set by Visa. DelayedCharges: Delayed charges are performed to process a supplemental account charge after original services have been rendered and respective payment has been processed. NoShow: Cardholders can use their Visa cards to make a guaranteed reservation with certain merchant segments. A guaranteed reservation ensures that the reservation will be honored and allows a merchant to perform a No Show transaction to charge the cardholder a penalty according to the merchant’s cancellation policy. Note: For merchants that accept token-based payment credentials to guarantee a reservation, it is necessary to perform a CIT (Account Verification Service) at the time of reservation to be able perform a No Show transaction later. Hinweis: Für Händler, die tokenbasierte Zahlungsinformationen akzeptieren, um eine Reservierung zu garantieren, ist es zum Zeitpunkt der Reservierung erforderlich, einen CIT (Kontoverifizierungsservice) durchzuführen, um später eine No-Show-Transaktion durchführen zu können. Note: It is always submitted in conjunction with the “schemeReferenceID” parameter. Please contact 1cs Helpdesk for the supported Acquirer and card brands.
Amount	n..10	M	Amount in the smallest currency unit (e.g. EUR Cent). Please contact the 1cs Helpdesk, if you want to capture amounts <100 (smallest currency unit).
Currency	a3	M	Currency, three digits DIN / ISO 4217, e.g. EUR, USD, GBP. Please find an overview here: Currency table
Card	JSON	M	Card data
Capture	ans..6	O	Determines the type and time of capture. AUTO: Capturing immediately after authorisation (default value). MANUAL: Capturing made by the merchant. Capture is normally initiated at time of delivery. <Number>: Delay in hours until the capture (whole number; 1 to 696).
BillingDescriptor	ans..22	O	A descriptor to be printed on a card holder’s statement. Please also refer to the additional comments made elsewhere for more information about rules and regulations.
OrderDesc	ans..768	M	Order description
AccVerify	JSON	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 exemption handling strategies
ThreeDSData	JSON	C	Object detailing authentication data in case authentication was performed through a third party or by the merchant
PriorAuthenticationInfo	JSON	O	Prior Transaction Authentication Information contains optional information about a 3-D Secure cardholder authentication that occurred prior to the current transaction
BrowserInfo	JSON	C	Accurate browser information are needed to deliver an optimized user experience. Required for 3-D Secure 2.0 transactions.
AccountInfo	JSON	O	The account information contains optional information about the customer account with the merchant. Optional for 3-D Secure 2.0 transactions.
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 available and different from billToCustomer) unless market or regional mandate restricts sending this information.
BillingAddress	JSON	C	Billing address. Required for 3-D Secure 2.0 (if available) unless market or regional mandate restricts sending this information.
ShippingAddress	JSON	C	Shipping address. If different from billingAddress, required for 3-D Secure 2.0 (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
SubMerchantPF	JSON	O	Object specifying SubMerchant (Payment Facilitator) details Only supported by SafeCharge
TermURL	ans..256	M	Only for 3-D Secure: URL of the shop which has been selected by the Access Control Server (ACS) of the bank to transmit the result of the authentication. The bank transmits the parameters PayID, TransID and MerchantID via GET and the PAResponse parameter via POST to the TermURL. In case of a merchant initiated recurring transaction the JSON objects (besides credentialOnFile and card), the URLNotify and TermURL are not mandatory parameters, because no 3-D Secure and no risk evaluation is done by the card issuing bank and the payment result is directly returned within the response.
URLNotify	ans..256	M	Complete URL which the 1cs Online Payment System 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. In case of a merchant initiated recurring transaction the JSON objects (besides credentialOnFile and card), the URLNotify and TermURL are not mandatory parameters, because no 3-D Secure and no risk evaluation is done by the card issuing bank and the payment result is directly returned within the response. Common notes: We recommend to use parameter “response=encrypt” to get an encrypted response by the 1cs Online Payment System 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.
UserData	ans..1024	O	If specified at request, Paygate forwards the parameter with the payment result to the shop.
MAC	an64	M	Hash Message Authentication Code (HMAC) with SHA-256 algorithm. Details can be found here: HMAC Authentication (Request) HMAC Authentication (Notify)

General parameters for credit card payments via socket connection

Please note the additional parameter for a specific credit card integration in the section “Specific parameters”

3.4.2 Response Elements (authentication)

The following table describes the result parameters with which the 1cs online payment system responds to your system

be prepared to receive additional parameters at any time and do not check the order of parameters

the parameters (e.g. MerchantId, RefNr) should not be checked case-sentive

Parameter	Format	CND	Beschreibung
MID	ans..30	M	MerchantID, assigned by the 1cs OPS
PayID	an32	M	ID assigned by the 1cs OPS for the payment, e.g. for referencing in batch files as well as for capture or credit request.
XID	an32	M	ID for all single transactions (authorisation, capture, credit note) for one payment assigned by the 1cs Online Payment System
TransID	ans..64	M	TransactionID provided by you which should be unique for each payment
RefNr		O	Reference number as given in request
Status	a..20	M	Status of the transaction. Values accepted: AUTHENTICATION_REQUEST PENDING FAILED
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!
Code	n8	M	Error code according to Paygate Response Codes (A4 Error codes)
UserData	ans..1024	O	If specified at request, the 1cs OPS forwards the parameter with the payment result to the shop.
Card	JSON	M	Card data
VisioningData	JSON	M	The Card Range Data data element contains information that indicates the most recent EMV 3-D Secure version supported by the ACS that hosts that card range. It also may optionally contain the ACS URL for the 3-D Secure Method if supported by the ACS and the DS Start and End Protocol Versions which support the card range.
ThreeDSLegacy	JSON	C	Object containing the data elements required to construct the Payer Authentication request in case of a fallback to 3-D Secure 1.0.

3.4.3 versioningData

The versioningData object will indicate the EMV 3-D Secure protocol versions (i.e. 2.1.0 or higher) that are supported by Access Control Server of the issuer.

If the corresponding protocol version fields are NULL it means that the BIN range of card issuer is not registered for 3-D Secure 2.0 and a fallback to 3-D Secure 1.0 is required for transactions that are within the scope of PSD2 SCA.

When parsing versioningData please also refer to the subelement errorDetails which will specify the reason if some fields are not pupoluated (e.g. Invalid cardholder account number passed, not available card range data, failure in encoding/serialization of the 3-D Secure Method data etc).

BASEURL= https://www.computop-paygate.com/

{

“threeDSServerTransID”: “14dd844c-b0fc-4dfe-8635-366fbf43468c”,

“acsStartProtocolVersion”: “2.1.0”,

“acsEndProtocolVersion”: “2.1.0”,

“dsStartProtocolVersion”: “2.1.0”,

“dsEndProtocolVersion”: “2.1.0”,

“threeDSMethodURL”: “http://www.acs.com/script“,

“threeDSMethodDataForm”: “eyJ0aHJlZURTTWV0aG9kTm90aWZpY2F0aW9uVVJMIjoiaHR0cHM6Ly93d3cuY29tcHV0b3AtcGF5Z2F0ZS5jb20vY2JUaHJlZURTLmFzcHg_YWN0aW9uPW10aGROdGZuIiwidGhyZWVEU1NlcnZlclRyYW5zSUQiOiIxNGRkODQ0Yy1iMGZjLTRkZmUtODYzNS0zNjZmYmY0MzQ2OGMifQ==”,

“threeDSMethodData”: {

“threeDSMethodNotificationURL”: “BASEURL/cbThreeDS.aspx?action=mthdNtfn”,

“threeDSServerTransID”: “14dd844c-b0fc-4dfe-8635-366fbf43468c”

}

3.5 3-D Secure Method

The 3-D Secure Method allows for additional browser information to be gathered by an ACS prior to receipt of the authentication request message (AReq) to help facilitate the transaction risk assessment. Support of 3-D Secure Method is optional and at the discretion of the issuer.

The versioningData object contains a value for threeDSMethodURL . The merchant is supposed to invoke the 3-D Secure Method via a hidden HTML iframe in the cardholder browser and send a form with a field named threeDSMethodData via HTTP POST to the ACS 3-D Secure Method URL.

3.5.1 3-D Secure Method: threeDSMethodURL

Please note that the threeDSMethodURL will be populated by the 1cs Online Payment System if the issuer does not support the 3-D Secure Method. The 3-D Secure Method Form Post as outlined below must be performed independently from whether it is supported by the issuer. This is necessary to facilitate direct communication between the browser and the 1cs Online Payment System in case of a mandated challenge or a frictionless flow.

3.5.2 3-D Secure Method: No issuer threeDSMethodURL

3.5.3 -D Secure Method Form Post

</form>

The ACS will interact with the Cardholder browser via the HTML iframe and then store the applicable values with the 3-D Secure Server Transaction ID for use when the subsequent authentication message is received containing the same 3-D Secure Server Transaction ID.

Netcetera 3DS Web SDK: You may use the operations init3DSMethod or createIframeAndInit3DSMethod at your discreation from the nca3DSWebSDK in order to iniatiate the 3-D Secure Method. Please refer to the Integration Manual at https://mpi.netcetera.com/3dsserver/doc/current/integration.html#Web_Service_API.

Once the 3-D Secure Method is concluded the ACS will instruct the cardholder browser through the iFrame response document to submit threeDSMethodData as a hidden form field to the 3-D Secure Method Notification URL.

3.5.4 ACS Response Document

<!DOCTYPE html>

<head>

<title>Identifying…</title>

</head>

<body>

var tdsMethodNotificationValue = ‘eyJ0aHJlZURTU2VydmVyVHJhbnNJRCI6ImUxYzFlYmViLTc0ZTgtNDNiMi1iMzg1LTJlNjdkMWFhY2ZhMiJ9’;

var form = document.createElement(“form”);

form.setAttribute(“method”, “post”);

form.setAttribute(“action”, “notification URL”);

addParameter(form, “threeDSMethodData”, tdsMethodNotificationValue);

document.body.appendChild(form);

form.submit();

function addParameter(form, key, value) {

var hiddenField = document.createElement(“input”);

hiddenField.setAttribute(“type”, “hidden”);

hiddenField.setAttribute(“name”, key);

hiddenField.setAttribute(“value”, value);

form.appendChild(hiddenField);

}

</script>

</body>

</html>

3.5.5 3-D Secure Method Notification Form

</form>

Please note that the threeDSMethodNotificationURL as embedded in the Base64 encoded threeDSMethodData value points to the 1cs Online Payment System and must not be modified. The merchant notification is delivered to the URLNotify as provided in the original request or as configured for the MerchantID in the 1cs OPS.

3.6 Authentication

If 3-D Secure Method is supported by the issuer ACS and was invoked by the merchant 1cs OPS will automatically continue with the authentication request once the 3-D Secure Method has completed (i.e. 3-D Secure Method Notification).

The authentication result will be transferred via HTTP POST to the URLNotify . It may indicate that the Cardholder has been authenticated, or that further cardholder interaction (i.e. challenge) is required to complete the authentication.

In case a cardholder challenge is deemed necessary The 1cs Online Payment system will transfer a JSON object within the body of HTTP browser response with the elements acsChallengeMandated , challengeRequest , base64EncodedChallengeRequest and acsURL . Otherwise, in a frictionless flow, the 1cs OPS will automatically continue and respond to the cardholder browser once the authorization completed.

3.6.1 Cardholder Challenge: Browser Response

3.6.2 Browser Challenge Response

Data Elements

Key	Format	CND	Description
acsChallengeMandated	boolean	M	Indication of whether a challenge is required for the transaction to be authorised due to local/regional mandates or other variable: true → Challenge is mandated by local/regional regulations false → Challenge is not mandated by local/regional regulations, but is deemed necessary by the ACS
challengeRequest	object	M	Challenge request object
base64EncodedChallengeRequest	string	M	Base64-encoded Challenge Request object
acsURL	string	M	Fully qualified URL of the ACS to be used to post the Challenge Request

Schema: Browser Challenge Response

{

“$schema”: “http://json-schema.org/draft-07/schema#“,

“type”: “object”,

“properties”: {

“acsChallengeMandated”: {“type”: “boolean”},

“challengeRequest”: {“type”: “object”},

“base64EncodedChallengeRequest”: {“type”: “string”},

“acsURL”: {“type”: “string”}

“required”: [“acsChallengeMandated”, “challengeRequest”, “base64EncodedChallengeRequest”, “acsURL”],

“additionalProperties”: false

}

Sample: Browser Challenge Response

{

“acsChallengeMandated”: false,

“challengeRequest”: {

“threeDSServerTransID”: “8a880dc0-d2d2-4067-bcb1-b08d1690b26e”,

“acsTransID”: “d7c1ee99-9478-44a6-b1f2-391e29c6b340”,

“messageType”: “CReq”,

“messageVersion”: “2.1.0”,

“challengeWindowSize”: “01”,

“messageExtension”: [

{

“name”: “emvcomsgextInChallenge”,

“id”: “tc8Qtm465Ln1FX0nZprA”,

“criticalityIndicator”: false,

“data”: “messageExtensionDataInChallenge”

}

]

“base64EncodedChallengeRequest”: “base64-encoded-challenge-request”,

“acsURL”: “acsURL-to-post-challenge-request”

}

3.6.3 Authentication Notification

The data elements of the authentication notification are listed in the table below.

Key	Format	CND	Description
MID	ans..30	M	MerchantID, assigned by the 1cs Online Payment System
PayID	an32	M	ID assigned by the 1cs OPS for the payment, e.g. for referencing in batch files as well as for capture or credit request.
TransID	ans..64	M	TransactionID provided by you which should be unique for each payment
Code	n8	M	Error code according to Paygate Response Codes (A4 Error codes)
MAC	an64	M	Hash Message Authentication Code (HMAC) with SHA-256 algorithm. Details can be found here: HMAC Authentication (Request) HMAC Authentication (Notify)
AuthenticationResponse	JSON	M	Response object in return of the authentication request with the ACS

3.6.4 Browser Challenge

If a challenge is deemed necessary (see challengeRequest) the browser challenge will occur within the cardholder browser. To create a challenge it is required to post the value base64EncodedChallengeRequest via an HTML iframe to the ACS URL.

Challenge Request

</form>

You may use the operations init3DSChallengeRequest or createIFrameAndInit3DSChallengeRequest from the nca3DSWebSDK in order submit the challenge message through the cardholder browser.

Init 3-D Secure Challenge Request – Example

<!DOCTYPE html>

<head>

<title>Init 3-D Secure Challenge Request – Example</title>

</head>

<body>

<!– This example will show how to initiate Challenge Reqeuests for different window sizes. –>

// Load all containers

iFrameContainerFull = document.getElementById(‘iframeContainerFull’);

container01 = document.getElementById(‘frameContainer01’);

container02 = document.getElementById(‘frameContainer02’);

container03 = document.getElementById(‘frameContainer03’);

container04 = document.getElementById(‘frameContainer04’);

container05 = document.getElementById(‘frameContainer05’);

// nca3DSWebSDK.init3DSChallengeRequest(acsUrl, creqData, container);

nca3DSWebSDK.init3DSChallengeRequest(‘http://example.com‘, ‘base64-encoded-challenge-request’, iFrameContainerFull);

// nca3DSWebSDK.createIFrameAndInit3DSChallengeRequest(acsUrl, creqData, challengeWindowSize, frameName, rootContainer, callbackWhenLoaded);

nca3DSWebSDK.createIFrameAndInit3DSChallengeRequest(‘http://example.com‘, ‘base64-encoded-challenge-request’, ’01’, ‘threeDSCReq01’, container01);

nca3DSWebSDK.createIFrameAndInit3DSChallengeRequest(‘http://example.com‘, ‘base64-encoded-challenge-request’, ’02’, ‘threeDSCReq02’, container02);

nca3DSWebSDK.createIFrameAndInit3DSChallengeRequest(‘http://example.com‘, ‘base64-encoded-challenge-request’, ’03’, ‘threeDSCReq03’, container03);

nca3DSWebSDK.createIFrameAndInit3DSChallengeRequest(‘http://example.com‘, ‘base64-encoded-challenge-request’, ’04’, ‘threeDSCReq04’, container04);

nca3DSWebSDK.createIFrameAndInit3DSChallengeRequest(‘http://example.com‘, ‘base64-encoded-challenge-request’, ’05’, ‘threeDSCReq05’, container05, () => {

console.log(‘Iframe loaded, form created and submitted’);

});

</script>

</body>

</html>

Once the cardholder challenge is completed, was cancelled or timed out the ACS will instruct the browser to post the results to the notfication URL as specified in the challenge request and to send a Result Request (RReq) via the Directory Server to the 3-D Secure Server.

Please note that the notification URL submited in the challenge request points to the 1cs Online Payment System and must not be changed.

3.7 Authorization

After successful cardholder authentication or proof of attempted authentication/verification is provided the 1cs Online Payment System will automatically continue with the payment authorization.

In case the cardholder authentication was not successful or proof proof of attempted authentication/verification can not be provided the 1cs Online Payment System will not continue with an authorization request.

In both cases the 1cs OPS will deliver a notification with the authentication result to the merchant specified URLNotify with the data elements as listed in the table below.

3.7.1 Payment Notification

Parameter	Format	CND	Beschreibung
MID	ans..30	M	MerchantID, assigned by the 1cs Online Payment System
MsgVer	ans..5	M	1cs Online Payment System Message version. Valid values: Value: 2.0 Description: With 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.
PayID	an32	M	ID assigned by the 1cs Online Payment System for the payment, e.g. for referencing in batch files as well as for capture or credit request.
XID	an32	M	ID for all single transactions (authorisation, capture, credit note) for one payment assigned by the 1cs OPS
TransID	ans..64	M	TransactionID provided by you which should be unique for each payment
SchemaReferenceID	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 the 1cs OPS merchants can continue to use the SchemeReferenceIDs for subscription plans that were created while using another PSP environment / 1cs OPS MerchantID / Acquirer ContractID / Acquirer.
TrxTime	an21	M	Transaction time stamp in format DD.MM.YYYY HH:mm:ssff
Status	a..20	M	Status of the transaction. Values accepted: Authorized OK (Sale) PENDING FAILED In case of Authentication-only the Status will be either OK or FAILED .
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!
Code	n8	M	Error code according to Paygate Response Codes (A4 Error codes)
MAC	an64	M	Hash Message Authentication Code (HMAC) with SHA-256 algorithm. Details can be found here: HMAC Authentication (Request) HMAC Authentication (Notify)
Card	JSON	M	Card data
IpInfo	JSON	O	Object containing IP information
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.
ExternalPaymentData	JSON	O	Optional additional data from acquirer/issuer/3rd party for authorization.
PCNr	n16	O	Pseudo Card Number: Random number generated by the 1cs sOnline Payment system which represents a genuine credit card number. The pseudo card number (PCN) starts with 0 and the last 3 digits correspond to those of the real card number. The PCN can be used like a genuine card number for authorisation, capture and credits. PCNr is a response value from the 1cs Online Payment System and is sent as CCNr in Request or part of card-JSON

3.7.2 Browser Payment Response

Additionally the JSON formatted data elements as listed below are transferred in the HTTP response body to the cardholder browser. Please note that the data elements (i.e. MID , Len , Data ) are base64 encoded.

Data Elements

Key	Format	CND	Description
MID	ans..30	M	MerchantID, assigned by the 1cs Online Payment System
Len	integer	M	Length of the unencrypted Data string
Data	string	M	Blowfish encrypted string containing a JSON object with MID , PayID and TransID

Schema

{

“$schema”: “http://json-schema.org/draft-07/schema#“,

“type”: “object”,

“properties”: {

“MID”: {

“type”: “string”

“Len”: {

“type”: “integer”

“Data”: {

“type”: “string”

}

“required”: [“MID”, “Len”, “Data”],

“additionalProperties”: false

}

Merchants are supposed to forward these data elements to their server for decryption and mapping agianst the payment notification. Based on the payment results the merchant server may deliver an appropriate response to the cardholder browser (e.g. success page).

Decrypted Data

Key	Format	CND	Description
MID	ans..30	M	MerchantID, assigned by the 1cs OPS
PayID	an32	M	ID assigned by the 1cs OPS for the payment, e.g. for referencing in batch files as well as for capture or credit request.
TransID	ans..64	M	TransactionID provided by you which should be unique for each payment

Sample decrypted Data

MID=YourMID&PayID=PayIDassignedbyPlatform&TransID=YourTransID

4 Capture / Credit / Reversal

4.1 Capture

Captures are possible via a Server-to-Server connection. To perform a capture via a Server-to-Server connection please use the following URL:

https://www.computop-paygate.com/capture.aspx

Notice: Please observe the reservation / authorisation deadlines of your acquirer (see General Terms and Conditions) so that you, as the merchant, ensure that the debits are submitted to our 1cs OPS within the correct period.

Notice: For security reasons, the 1cs Online Payment System rejects all payment requests with formatting errors. Therefore, please use the correct data type for each parameter.

The following table describes the encrypted payment request parameters:

Key	Format	CND	Description
MerchantID	ans..30	M	MerchantID, assigned by First Cash Solution. Additionally this parameter has to be passed in plain language too.
Amount	n..10	M	Amount in the smallest currency unit (e.g. EUR Cent) Please contact the 1cs support, if you want to capture amounts < 100 (smallest currency unit).
Currency	a3	M	Currency, three digits DIN / ISO 4217, e.g. EUR, USD, GBP. Please find an overview here: A1 Currency table EN
MAC	an64	M	Hash Message Authentication Code (HMAC) with SHA-256 algorithm. Details can be found here: HMAC Authentication (Request) HMAC Authentication (Notify)
PayID	an32	M	ID assigned by the 1cs Online Payment System for the payment e.g. for referencing in batch files as well as for capture or credit request.
TransID	ans..64	M	TransactionID which should be unique for each payment. Please note for some connections the different formats that are given within the specific parameters.
RefNr	ns..30	C	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 First Cash Solution settlement file (CTSF) we cannot add the additional payment data. (not with EVO Payments, for CardComplete in the format an..25, for Cofidis in the format n..15, for Omnipay in the format ns..15, for RBI in the format ns..20) Only ASCII characters are allowed. Special characters such as (“umlauts”, …) are not permitted and may have to be replaced by ASCII characters (e.g. ü → ue, é → e, …).
ReqID	ans..32	O	To avoid double payments / actions, enter an alphanumeric value which identifies your transaction and may be assigned only once. If the transaction / action is submitted again with the same ReqID, 1cs OPS will not carry out the payment or new action, but will just return the status of the original transaction / action. Please note that the 1cs OPS must have a finalized transaction status for the first initial action. Submissions with identical ReqID for an open status will be processed regularly. Notice: Please note that a ReqID is only valid for 12 month, then it gets deleted at the 1cs OPS.
FinishAuth	a1	C	Only with ETM: Transmit value <Y> in order to stop the renewal of guaranteed authorisations and rest amounts after partial captures. Please use this parameter only if you are using the additional function ETM (Extended Transactions Managament). (not with Clearhaus)
Textfeld1	ans..30	O	Card holder information: Name (not with Clearhaus)
Textfeld2	ans..30	O	Card holder information: City (not with Clearhaus)
CHDesc	ans..22	OC	Only with Clearhaus: Text printed on the customer’s credit card bill. Only printable ASCII characters from 0x20 to 0x7E

Parameters for captures of credit card payments

The following table describes the result parameters with which the 1cs online payment system responds to your system

be prepared to receive additional parameters at any time and do not check the order of parameters

the parameters (e.g. MerchantId, RefNr) should not be checked case-sentive

Key	Format	CND	Description
MID	ans..30	M	MerchantID, assigned by First Cash Solution
PayID	an32	M	ID assigned by the 1cs Online Payment System for the payment, e.g. for referencing in batch files as well as for capture or credit request.
XID	an32	M	ID for all single transactions (authorisation, capture, credit note) for one payment assigned by the 1cs Online Payment System
Code	n8	M	Error code according to the 1cs Online Payment System Response Codes Excel file
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!
TransID	ans..64	M	Merchant’s transaction number. Please note for some connections the different formats that are given within the specific parameters.
Status	a..50	M	OK or FAILED
RefNr	ns..30	C	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 First Cash Solution settlement file (CTSF) we cannot add the additional payment data. Only ASCII characters are allowed. Special characters such as (“umlauts”, …) are not permitted and may have to be replaced by ASCII characters (e.g. ü → ue, é → e, …).
AID	n6	OC	Only in the case of Card Complete: Authorisation ID returned by Card Complete
Amount	n..10	OC	Only with Clearhaus: Amount in the smallest currency unit (e.g. EUR Cent) If the actual amount differs from the requested amount this will be returned. Only with MasaPay: The amount has to be equal to the originally authorised amount.
CodeExt	n5	OC	Only with Clearhaus: Only if configured: External error code (downstream system). Only with MasaPay: Format ans..10, error code from MasaPay.
ErrorText	ans.128	OC	Only with Clearhaus: Detailed Clearhaus error message. Only with MasaPay: Format ans..128, detailed MasaPay error message. Is returned only if Status=FAILED. Use is possible only in agreement with First Cash Solution support.
TransactionID	ans36	OC	Only with Clearhaus: Transaction number from Clearhaus
GuWID	ans..22	O	Only with Wirecard: TransactionID of the Acquiring Bank
TID	n..15	M	Only with Cofidis: If RefNr was submitted, it’s value will be returned. Otherwise the first 15 digits of TransactionID will be returned.

Response parameters for captures of credit card payments

4.2 Credit with reference

Credits (refunds) are possible via a Server-to-Server connection. the 1cs Online Payment System permits credits which relate to a capture previously activated by the 1cs Online Payment System and allows merchants to carry out credits without a reference transaction. This section describes the processing of credits with reference transactions. If you refer to a capture for a Credit, the amount of the Credit is limited to the amount of the previous capture.

To carry out a credit with a reference transaction, please use the following URL:

https://www.computop-paygate.com/credit.aspx

Notice: For security reasons, the 1cs Online Payment System rejects all payment requests with formatting errors. Therefore, please use the correct data type for each parameter.

The following table describes the encrypted payment request parameters:

Key	Format	CND	Description
MerchantID	ans..30	M	MerchantID, assigned by First Cash Solution. Additionally this parameter has to be passed in plain language too.
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 DIN / ISO 4217, e.g. EUR, USD, GBP. Please find an overview here: Currency table
MAC	an64	M	Hash Message Authentication Code (HMAC) with SHA-256 algorithm. Details can be found here: HMAC Authentication (Request) HMAC Authentication (Notify)
PayID	an32	M	ID assigned by the 1cs Online Payment System for the payment, e.g. for referencing in batch files as well as for capture or credit request.
TransID	ans..64	M	TransactionID which should be unique for each payment. Please note for some connections the different formats that are given within the specific parameters.
RefNr	an..30	C	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 First Cash Solution settlement file (CTSF) we cannot add the additional payment data. Only ASCII characters are allowed. Special characters such as (“umlauts”, …) are not permitted and may have to be replaced by ASCII characters (e.g. ü → ue, é → e, …).
OrderDesc	ans..768	O	Description of refunded goods, unit prices, merchant’s comment etc. (not with Clearhaus)
ReqID	ans..32	O	To avoid double payments / actions, enter an alphanumeric value which identifies your transaction and may be assigned only once. If the transaction / action is submitted again with the same ReqID, 1cs OPS will not carry out the payment or new action, but will just return the status of the original transaction / action. Please note that the 1cs OPS must have a finalized transaction status for the first initial action. Submissions with identical ReqID for an open status will be processed regularly. Notice: Please note that a ReqID is only valid for 12 month, then it gets deleted at the 1cs Online Payment System.
Textfeld1	ans..30	O	Card holder information: Name (not with Clearhaus)
Textfeld2	ans..30	O	Card holder information: City (not with Clearhaus)
CHDesc	ans..22	OC	Only with Clearhaus: Text printed on the customer’s credit card bill. Only printable ASCII characters from 0x20 to 0x7E
TID	ans..30	OC	Only with SafeCharge: TransaktioncID of the capture to be credited, if the merchant wants to credit a specifc capture. If the parameter is nut submitted the last capture will be credited.
Additional parameters for Wirecard connection (for Visa Direct)
refundType	enum	C	Type of refund. Possible values: “p2p”, “md”, “acc2acc”. “ccBill”, “fd”
receiverFirstName	an..12	C	First name of the receiver. Mandatory for cross-border transactions.
receiverLastName	an..12	C	Last name of the receiver. Mandatory for cross-border transactions.
senderAccountNumber	n..12	C	Account number of the sender. Mastercard: Mandatory. Visa: Mandatory, if RefNr is empty.
senderFirstName	an..12	C	First name of the sender. Mastercard: Mandatory. Visa: Mandatory for US domestic transactions and cross-border money transfers.
senderLastName	an..12	C	Last name of the sender. Mastercard: Mandatory. Visa: Optional.
senderAddrStreet	an..25	C	Street name of the sender. Mastercard: Optional. Visa: Mandatory for US domestic transactions and cross-border money transfers.
senderAddrStreetNr	an..25	C	Street number of the sender. Mastercard: Optional. Visa: Mandatory for US domestic transactions and cross-border money transfers.
senderAddrCity	an..32	C	Town/city of the sender. Mastercard: Optional. Visa: Mandatory for US domestic transactions and cross-border money transfers.
senderAddrState	a2	C	State of the sender. Mastercard: Mandatory, if senderAddrCountry=US or Canada. Visa: Mandatory for US domestic transactions and cross-border money transfers.
senderAddrCountry	a2	C	Country of the sender. Mastercard: Optional. Visa: Mandatory if country is US and for cross-border money transfers.

Parameters for credits of credit card payments

The following table describes the result parameters with which the 1cs online payment system responds to your system

be prepared to receive additional parameters at any time and do not check the order of parameters

the parameters (e.g. MerchantId, RefNr) should not be checked case-sentive

Key	Format	CND	Description
MID	ans..30	M	MerchantID, assigned by First Cash Solution
PayID	an32	M	ID assigned by the 1cs Online Payment System for the payment, e.g. for referencing in batch files as well as for capture or credit request.
XID	an32	M	ID for all single transactions (authorisation, capture, credit note) for one payment assigned by the 1cs Online Payment System
Code	n8	M	Error code according to the 1cs Online Payment System Response Codes Excel file
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!
TransID	ans..64	M	Merchant’s transaction number. Please note for some connections the different formats that are given within the specific parameters.
Status	a..50	M	OK or FAILED
AID	n6	OC	Only in the case of Card Complete: Authorisation ID returned by Card Complete
RefNr	an..25	OC	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 First Cash Solution settlement file (CTSF) we cannot add the additional payment data. Only for Card Complete, for Clearhaus (ans..30, optional, only printable ASCII characters from 0x20 to 0x7E), for RBI (ns..20, optional), for MasaPay (ns..30, optional), for Cofidis (n..15, optional). Only ASCII characters are allowed. Special characters such as (“umlauts”, …) are not permitted and may have to be replaced by ASCII characters (e.g. ü → ue, é → e, …).
Amount	n..10	OC	Only with Clearhaus: Amount in the smallest currency unit (e.g. EUR Cent) If the actual amount differs from the requested amount this will be returned. Only with MasaPay: The amount has to be equal to the originally authorised amount.
CodeExt	n5	OC	Only with Clearhaus: Only if configured: External error code (downstream system). Only with MasaPay: Format ans..10, error code from MasaPay.
ErrorText	ans.128	OC	Only with Clearhaus: Detailed Clearhaus error message. Only with MasaPay: Format ans..128, detailed MasaPay error message. Is returned only if Status=FAILED. Use is possible only in agreement with First Cash Solution support.
TransactionID	ans36	OC	Only with Clearhaus: Transaction number from Clearhaus

Response parameters for credits of credit card payments

4.3 Credit without reference

The 1cs Online Payment System can carry out Credits which do not relate to a previous capture. In this case the credit must be transferred to the 1cs Online Payment System as a completely new payment transaction. Please contact the First Cash Solution Helpdesk for help in using the described additional functions.

Notice: Please note that credits without reference to a previous capture generate higher costs with your Acquiring Bank. If you are frequently unable to make reference to the capture you should agree this with your Acquiring Bank.

To carry out a Credit without a reference transaction via a Server-to-Server connection, please use the following URL:

https://www.computop-paygate.com/creditex.aspx

Notice: For security reasons, the 1cs Online Payment System rejects all payment requests with formatting errors. Therefore, please use the correct data type for each parameter.

The following table describes the encrypted payment request parameters:

Key	Format	CND	Description
MerchantID	ans..30	M	MerchantID, assigned by First Cash Solution. Additionally this parameter has to be passed in plain language too.
Amount	n..10	M	Amount in the smallest currency unit (e.g. EUR Cent) Please contact the 1cs Support, if you want to capture amounts < 100 (smallest currency unit).
Currency	a3	M	Currency, three digits DIN / ISO 4217, e.g. EUR, USD, GBP. Please find an overview here: Currency table
MAC	an64	M	Hash Message Authentication Code (HMAC) with SHA-256 algorithm. Details can be found here: HMAC Authentication (Request) HMAC Authentication (Notify)
TransID	ans..64	M	TransactionID which should be unique for each payment. Please note for some connections the different formats that are given within the specific parameters.
RefNr	ns..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 First Cash Solution settlement file (CTSF) we cannot add the additional payment data. (not with EVO Payments, Only for CardComplete, for Clearhaus (ns..30, optional, only printable ASCII characters from 0x20 to 0x7E), for RBI (ns..20, optional), for MasaPay (ns..30, optional), for Cofidis (n..15, optional).) Only ASCII characters are allowed. Special characters such as (“umlauts”, …) are not permitted and may have to be replaced by ASCII characters (e.g. ü → ue, é → e, …).
OrderDesc	ans..768	O	Description of refunded goods, unit prices, merchant’s comment etc. (not with Clearhaus)
ReqID	ans..32	O	To avoid double payments or actions (e.g. by ETM), enter an alphanumeric value which identifies your transaction and may be assigned only once. If the transaction or action is submitted again with the same ReqID, 1cs Online Payment System will not carry out the payment or new action, but will just return the status of the original transaction or action. Please note that the 1cs OPS must have a finalized transaction status for the first initial action (authentication/authorisation). This does not apply to 3-D Secure authentications that are terminated by a timeout. The 3-D Secure Timeout status does not count as a completed status in which the ReqID functionality on the 1cs Online Payment System does not take effect. Submissions with identical ReqID for an open status will be processed regularly. Notice: Please note that a ReqID is only valid for 12 month, then it gets deleted at the 1cs OPS.
CCNr	n..19	M	Credit card number at least 12-digit, numerical without spaces It can be filled: either with the real credit card number (PAN) or with the pseudo card number that you have received previously in a 1cs OPS response in parameter PCNr. With 3-D Secure 2.x the CCNr (PAN or PCNr) is sent as card.JSON. We recommend to use “Hosted Payment Page” or Credit Card Form (paySSL) for simplified PCI DSS certification and usage of PCNr.
CCCVC	n..4	O
CCExpiry	n6	M	Expiry date of the credit card in the format YYYYMM, e.g. 202507.
CCBrand	a..22	M	Credit card brand. Please note the spelling! According to table of credit card brands!
OrderDesc	ans..768	MC	Not with Clearhaus: Description of refunded goods, unit prices, merchant’s comment etc.
UserData	ans..1024	OC	Only with Clearhaus: If specified at request, the 1cs Online Payment System forwards the parameter with the payment result to the shop.
Textfeld1	ans..30	O	Not with Clearhaus: Card holder information: Name
Textfeld2	ans..30	O	Not with Clearhaus: Card holder information: City
CHDesc	ans..34	OC	Only with Clearhaus, format ans..22: Text printed on the customer’s credit card bill. Only printable ASCII characters from 0x20 to 0x7E Only for Credorax: Text printed on the customer’s credit card bill. This function must be enabled by Credorax and have the following structure. 1) merchant DBA name (up to 20 characters) 2) asterisk 3) additional text (up to 13 characters). This value can be alternatively permanently defined by 1cs Helpdesk
CreditCardHolder	an..255	MC	Only with Credorax, ECPCC: Name of the card holder
Email	ans..64	MC	Only with Credorax, ECPCC: Email address of the customer
IPAddr	ans..15	OC	Only with Credorax, ECPCC: Customer´s IP address
PaymentOfWinnings	ans..4	OC	In the case of the acquirer EMS (Omnipay) the merchant can control CFT credit notes in this way. Transfer PaymentOfWinnings=True to credit a win rather than simply repaying a paid amount.
PaymentAddData	JSON	C	Only with Omnipay: Additional data if PaymentOfWinnings=True
TransactionID	an..150	M	Additional reference number
Further address parameters in case of ECPCC connection
DateOfBirth	n8	O	Date of birth of the customer in format YYYYMMDD
Phone	n..32	O	Customer’s phone number
FirstName	ans..255	M	First name of the customer
LastName	ans..255	M	Last name of the customer
AddrStreet	ans..255	O	Street name
AddressAddition	ans..255	O	Address c/o
AddrZip	an..9	O	Postcode
AddrCity	ans..255	O	City
AddrState	a2	O	Code of the customer’s Federal State
AddrCountryCode	a2	M	Country code according to ISO-3166-1, alphanumeric 2 chars
sdFirstName	ans..255	O	First name in the delivery address
sdLastName	ans..255	O	Surname in the delivery address
sdStreet	ans..255	O	Street name in the delivery address
sdAddressAddition	ans..255	O	Address addition in the delivery address
sdZIPCode	an..9	O	Postcode in the delivery address
sdCity	ans..255	O	Town/city in the delivery address
sdState	a2	O	Code of Federal State in the delivery address
sdCountryCode	a2	O	Country code of delivery address according to ISO-3166-1, alphanumeric 2 chars
Further address parameters in case of Kalixa connection
IPAddr	ans..15	M	Customer´s IP address
BrowserSessionID	ans..64	M	Customer´s Session ID
CreditCardHolder	ans..100	M	Name of the card holder
CustomerID	an..20	M	Customer number: Number to identify the customer
Name	ans..100	C	User name of the customer
FirstName	ans..100	C	First name of the customer
LastName	ans..100	C	Last name of the customer
Email	ans..64	C	Email address of the customer
Language	a2	C	Language of the customer according to ISO, alphanumeric 2-digits
sdFirstName	ans..100	C	First name in the delivery address
sdLastName	ans..100	C	Surname in the delivery address
sdStreet	ans..200	C	Street name in the delivery address
sdStreetNr	ans..5	C	Street number in the delivery address
sdZIPCode	an..20	C	Postcode in the delivery address
sdCity	ans..40	C	Town/city in the delivery address
sdState	a2	C	Code of Federal State in the delivery address
sdCountryCode	a2	C	Country code of delivery address according to ISO-3166-1, alphanumeric 2 chars
Further address parameters in case of Vantiv connection
bdFirstName	ans..25	O	First name in the invoicing address
bdLastName	ans..25	O	Last name in the invoicing address
bdStreet	ans..35	O	Street name in the invoicing address Please note that bdStreet and bdStreetNr together may have 34 characters maximum. bdStreet and bdStreetNr are combined with a space character between and forwarded together. The total content is truncated after 35 characters.
bdStreetNr	ans..35	O	Street number in the invoicing address Please note that bdStreet and bdStreetNr together may have 34 characters maximum. bdStreet and bdStreetNr are combined with a space character between and forwarded together. The total content is truncated after 35 characters.
bdStreet2	ans..35	O	Address addition in the billing address
bdZIPCode	ans..20	O	Postcode in the invoicing address
bdCity	ans..35	O	Town/city in the invoicing address
bdState	ans..30	O	State/country in the invoicing address
bdCountryCode	a2	O	Country code of invoicing address according to ISO-3166-1, alphanumeric 2 chars
bdMail	ans..100	O	Email address in the invoicing address
bdPhone	ans..20	O	Phone number in the invoicing address

Parameters for credits of credit card payments without reference

The following table describes the result parameters with which the 1cs online payment system responds to your system

be prepared to receive additional parameters at any time and do not check the order of parameters

the parameters (e.g. MerchantId, RefNr) should not be checked case-sentive

Key	Format	CND	Description
MID	ans..30	M	MerchantID, assigned by First Cash Solution
PayID	an32	M	ID assigned by the 1cs Online Payment System for the payment, e.g. for referencing in batch files as well as for capture or credit request.
XID	an32	M	ID for all single transactions (authorisation, capture, credit note) for one payment assigned by the 1cs Online Payment System
Code	n8	M	Error code according to the 1cs Online Payment System Response Codes Excel file
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!
TransID	ans..64	M	Merchant’s transaction number. Please note for some connections the different formats that are given within the specific parameters.
Status	a..50	M	OK or FAILED
AID	n6	OC	Only in the case of Card Complete: Authorisation ID returned by Card Complete
RefNr	an..25	OC	Only for Card Complete: If a RefNr has been transmitted, it is returned.Only ASCII characters allowed, special characters (“Umlaute”, diacritics) are not allowed and must be replaced by their ASCII-representation (e.g. ü → ue, é → e, …).
Amount	n..10	OC	Only with Clearhaus: Amount in the smallest currency unit (e.g. EUR Cent) If the actual amount differs from the requested amount this will be returned.
CodeExt	n5	OC	Only with Clearhaus: Only if configured: External error code (downstream system)
ErrorText	ans.128	OC	Only with Clearhaus: Detailed Clearhaus error message. Is returned only if Status=FAILED. Use is possible only in agreement with First Cash Solution support.
UserData	ans..1024	OC	Only with Clearhaus: If specified at request, the 1cs Online Payment System forwards the parameter with the payment result to the shop.
TransactionID	ans36	OC	Only with Clearhaus: Transaction number from Clearhaus
PaymentSenderReference	an..19	C	Only with Omnipay: Reference number generated by the Acquirer that will be used to identify the payment transaction. It can be returned for MasterCard Payment of winnings transactions when the required additional parameters are submitted in the request.

Response parameters for credits of credit card payments without reference

4.4 Reversal

A credit card authorization lowers the customer’s credit line. the 1cs Online Payment System can reverse an authorization so that it no longer block the limit any more. Use the following URL:

https://www.computop-paygate.com/reverse.aspx

Notice:Reverse.aspx does not only reverse authorizations, but any LAST TRANSACTION STAGE!! If the last transaction was a capture, Reverse.aspx initiates the reverse, e.g. a credit. Therefore, the utmost caution is urged. Use is at your own risk. We recommend checking the transaction status with Inquire.aspx before using Reverse.aspx.

Notice: For security reasons, the 1cs Online Payment System rejects all payment requests with formatting errors. Therefore, please use the correct data type for each parameter.

The following table describes the encrypted payment request parameters:

Key	Format	CND	Description
MerchantID	ans..30	M	MerchantID, assigned by First Cash Solution. Additionally this parameter has to be passed in plain language too.
Amount	n..10	M	Amount in the smallest currency unit (e.g. EUR Cent). Please contact the 1cs support, if you want to capture amounts <100 (smallest currency unit).
Curency	a3	M	Currency, three digits DIN / ISO 4217, e.g. EUR, USD, GBP. Please find an overview here: Currency table
MAC	an64	M	Hash Message Authentication Code (HMAC) with SHA-256 algorithm. Details can be found here: HMAC Authentication (Request) HMAC Authentication (Notify)
PayID	an32	M	ID assigned by the 1cs OPS for the payment, e.g. for referencing in batch files as well as for capture or credit request.
TransID	ans..64	M	Merchant ID for the identification of the payment process to be reversed. Please note for some connections the different formats that are given within the specific parameters.
RefNr	ans..30	OC	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 First Cash Solution settlement file (CTSF) we cannot add the additional payment data. Only for Clearhaus (only printable ASCII characters from 0x20 to 0x7E), for MasaPay. Only ASCII characters are allowed. Special characters such as (“umlauts”, …) are not permitted and may have to be replaced by ASCII characters (e.g. ü → ue, é → e, …).
ReqID	ans..32	O	To avoid double payments / actions, enter an alphanumeric value which identifies your transaction and may be assigned only once. If the transaction / action is submitted again with the same ReqID, 1cs OPS will not carry out the payment or new action, but will just return the status of the original transaction / action. Please note that the 1cs OPS must have a finalized transaction status for the first initial action. Submissions with identical ReqID for an open status will be processed regularly. Notice: Please note that a ReqID is only valid for 12 month, then it gets deleted at the 1cs OPS.

Parameters for reversals of credit card payments

The following table describes the 1cs Online Payment System response parameters:

– pls. be prepared to receive additional parameters at any time and do not check the order of parameters

– the key (e.g. MerchantId, RefNr) should not be checked case-sentive

Key	Format	CND	Description
MID	ans..30	M	MerchantID, assigned by First Cash Solution
PayID	an32	M	ID assigned by the 1cs Online Payment System for the payment, e.g. for referencing in batch files as well as for capture or credit request.
XID	an32	M	ID for all single transactions (authorisation, capture, credit note) for one payment assigned by the 1cs Online Payment System
Code	n8	M	Error code according to 1cs Online Payment System Response Codes (A4 Error codes)
Description	ans..1024	M	Further details if payment is rejected. Please do not use the Description but the Code parameter for the transaction status analysis!
TransID	ans..64	M	Merchant’s transaction number. Please note for some connections the different formats that are given within the specific parameters.
Status	a..50	M	OK or FAILED
RefNr	an..25	OC	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 First Cash Solution settlement file (CTSF) we cannot add the additional payment data. Only for Card Complete, for Clearhaus (ans..30, only printable ASCII characters from 0x20 to 0x7E), for MasaPay (ns..30). Only ASCII characters are allowed. Special characters such as (“umlauts”, …) are not permitted and may have to be replaced by ASCII characters (e.g. ü → ue, é → e, …).
TransactionID	ans36	OC	Only with Clearhaus: Transaction number from Clearhaus

Response parameters for reversals of credit card payments

4.5 Reversal of an authorisation extension

A credit card authorisation is valid for only 7 to 30 days. In order to maintain your payment claim in the case of longer delivery times, the 1cs Online Payment System enables the automatic renewal of the authorisation. Renewal of the authorisation is also important for instalments or partial deliveries because the outstanding amount is invalid in the case of partial captures.

If you use authorisation renewal, the 1cs Online Payment System renews your authorisations until the payment has been captured fully. Amongst other things the customer’s card limit is reduced by the authorised amount. In order to restore the card limit again, for example because the order cannot be fully delivered, you need to specifically cancel the authorisation renewal with the following URL:

https://www.computop-paygate.com/cancelAuth.aspx

Notice: CancelAuth cancels only the recurrence of the authorisation. If you wish to unblock the customer’s card limit, please reverse the authorisation in accordance with the section above.

Notice: For security reasons, the 1cs Online Payment System rejects all payment requests with formatting errors. Therefore, please use the correct data type for each parameter.

The following table describes the encrypted payment request parameters:

Key	Format	CND	Description
MerchantID	ans..30	M	MerchantID, assigned by First Cash Solution. Additionally this parameter has to be passed in plain language too.
PayID	an32	M	ID assigned by the 1cs Online Payment System for the payment, e.g. for referencing in batch files as well as for capture or credit request.
TransID	ans..64	M	TransID for the identification of the payment process to be reversed
MAC	an64	M	Hash Message Authentication Code (HMAC) with SHA-256 algorithm. Details can be found here: HMAC Authentication (Request) HMAC Authentication (Notify)

Parameters for reversal of an authorisation extension

The following table describes the result parameters with which the 1cs online payment system responds to your system

be prepared to receive additional parameters at any time and do not check the order of parameters

the parameters (e.g. MerchantId, RefNr) should not be checked case-sentive

Key	Format	CND	Description
MID	ans..30	M	MerchantID, assigned by First Cash Solution
PayID	an32	M	ID assigned by the 1cs Online Payment System for the payment, e.g. for referencing in batch files as well as for capture or credit request.
TransID	ans..64	M	Merchant’s transaction number.
Status	a..50	M	OK (URLSuccess) or FAILED (URLFailure)
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!
Code	n8	M	Error code according to the 1cs Online Payment System Response Codes Excel file

Result parameters for reversals of an authorisation extension

4.6 Credit card payment via POS terminals

To make a credit card payment via a POS terminal (POS: Point of Sale), send the payment request to the following URL:

https://www.computop-paygate.com/stationary.aspx

Notice: For security reasons, the 1cs Online Payment System rejects all payment requests with formatting errors. Therefore, please use the correct data type for each parameter.

The following table describes the encrypted payment request parameters:

Key	Format	CND	Description
MerchantID	ans..30	M	MerchantID, assigned by First Cash Solution. Additionally this parameter has to be passed in plain language too.
Amount	n..10	M	Amount in the smallest currency unit (e.g. EUR Cent) Please contact the 1cs support, if you want to capture amounts < 100 (smallest currency unit).
Currency	a3	M	Currency, three digits DIN / ISO 4217, e.g. EUR, USD, GBP., Please find an overview here: Currency table
MAC	an64	M	Hash Message Authentication Code (HMAC) with SHA-256 algorithm. Details can be found here: HMAC Authentication (Request) HMAC Authentication (Notify)
TransID	ans..64	M	TransactionID which should be unique for each payment
RefNr	ns..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 First Cash Solution settlement file (CTSF) we cannot add the additional payment data. Format must be mutually agreed beforehand with First Cash Solution! Only ASCII characters are allowed. Special characters such as (“umlauts”, …) are not permitted and may have to be replaced by ASCII characters (e.g. ü → ue, é → e, …).
CCNr	n..16	M	Credit card number at least 12-digit, numerical without spaces
CCCVC	n..4	O	Card verification number: The last 3 digits on the signature strip of the credit card. 4 numbers in the case of American Express.
CCExpiry	n6	M	Expiry date of the credit card in the format YYYYMM, e.g. 201707.
CCBrand	a..22	M	Credit card brand. Please note the spelling! According to table of credit card brands!
Track2	ans..80	M	Hexadecimal data on track 2 of the credit card
Track3	ans..80	M	Hexadecimal data on track 3 of the credit card
OrderDesc	ans..768	M	Description of purchased goods, unit prices etc.
Capture	ans..6	O	Determines the type and time of capture. AUTO: capturing immediately after authorisation (default value). MANUAL: capturing made by the merchant. <Number>: Delay in hours until the capture (whole number; 1 to 696).
ReqID	ans..32	O	To avoid double payments, enter an alphanumeric value which identifies your transaction and may be assigned only once. If the transaction is submitted again with the same ReqID, the 1cs Online Payment System will not carry out the payment, but will just return the status of the original transaction / action. Please note that the 1cs OPS must have a finalized transaction status for the first initial action. Submissions with identical ReqID for an open status will be processed regularly. Notice: Please note that a ReqID is only valid for 12 month, then it gets deleted at the 1cs Online Payment System.

Parameters for credit card payments via POS terminals

The following table describes the result parameters with which the 1cs online payment system responds to your system

be prepared to receive additional parameters at any time and do not check the order of parameters

the parameters (e.g. MerchantId, RefNr) should not be checked case-sentive

Key	Format	CND	Description
MID	ans..30	M	MerchantID, assigned by First Cash Solution
PayID	an32	M	ID assigned by the 1cs Online Payment System for the payment, e.g. for referencing in batch files as well as for capture or credit request.
XID	an32	M	ID for all single transactions (authorisation, capture, credit note) for one payment assigned by the 1cs Online Payment System
Code	n8	M	Error code according to the 1cs Online Payment System Response Codes Excel file
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!
TransID	ans..64	M	Merchant’s transaction number
TID	n..20	M	Usually a nine-digit terminal number
AuthCode	ans..6	M	Acquiring Bank’s authorisation code
Status	a..50	M	AUTHORIZED or FAILED. OK status applies only to Sale transactions.

Response parameters for credit card payments via POS terminals

4.7 Reversal of POS credit card payments

To reverse the capture of a credit card payment via a stationary terminal, please use the following URL:

https://www.computop-paygate.com/stationary_rev.aspx

The following table describes the result parameters with which the 1cs online payment system responds to your system

be prepared to receive additional parameters at any time and do not check the order of parameters

the parameters (e.g. MerchantId, RefNr) should not be checked case-sentive

Key	Format	CND	Description
MerchantID	ans..30	M	MerchantID, assigned by First Cash Solution. Additionally this parameter has to be passed in plain language too.
PayID	an32	M	ID assigned by the 1cs Online Payment System for the payment, e.g. for referencing in batch files as well as for capture or credit request.
XID	an32	M	ID for all single transactions (authorisation, capture, credit note) for one payment assigned by the 1cs Online Payment System
TransID	ans..64	M	ID of merchant for the identification of the payment process to be reversed
MAC	an64	M	Hash Message Authentication Code (HMAC) with SHA-256 algorithm. Details can be found here: HMAC Authentication (Request) HMAC Authentication (Notify)

Parameters for reversal of credit card payments via POS terminals

The following table describes the result parameters with which the 1cs online payment system responds to your system

be prepared to receive additional parameters at any time and do not check the order of parameters

the parameters (e.g. MerchantId, RefNr) should not be checked case-sentive

Key	Format	CND	Description
MID	ans..30	M	MerchantID, assigned by First Cash Solution
PayID	an32	M	ID assigned by the 1cs Online Payment System for the payment, e.g. for referencing in batch files as well as for capture or credit request.
TransID	ans..64	M	Merchant’s transaction number
Status	a..50	M	OK (URLSuccess) or FAILED (URLFailure)
Code	n8	M	Error code according to the 1cs Online Payment System Response Codes Excel file

Response parameters for reversal of credit card payments via POS terminals

5 PayNow

5.1 Silent Mode for credit cards with SSL and 3D Secure method

PayNow links the benefits of the 1cs Online Payment System forms and Server-to-Server connections: AS opposed to the the 1cs Online Payment System form, where the form is loaded from the the 1cs Online Payment System server by calling payssl.aspx, the PayNow form has to be provided by the merchant’s system. The form uses the same parameters as described here below.

In contrast to the the 1cs Online Payment System form, the parameters are not forwarded as URL parameters as is the case when calling the payssl.aspx, but as form input parameters. By the way for calling the PayNow.aspx the same parameters can be used as for PaySSL.aspx.

The 1cs Online Payment System-Formular	PayNow
payssl.aspx?MerchantID=[mid]&Len=[len]&Data=[data]	`<form action=paynow.aspx> <input type="hidden" name="MerchantID" value=[mid]> <input type="hidden" name="Len" value=[len]> <input type="hidden" name="Data" value=[data]> : </form>`

The credit card data must be transmitted to paynow.aspx with the following parameters:

Key	Format	CND	Description
CCNr	n..19	M	Credit card number at least 12-digit, numerical without spaces It can be filled: either with the real credit card number (PAN) or with the pseudo card number that you have received previously in a Paygate response in parameter PCNr. With 3-D Secure 2.x the CCNr (PAN or PCNr) is sent as card.JSON. We recommend to use “Hosted Payment Page” or Credit Card Form (paySSL) for simplified PCI DSS certification and usage of PCNr.
CCCVC	n3	O	Card verification number: The last 3 digits on the signature strip of the credit card
CCExpiry	n6	M	Expiry date of the credit card in the format YYYYMM, e.g. 201807.
CCBrand	a..22	M	Credit card brand. Please note the spelling! According to table of credit card brands!

PayNow parameters for 3-D Secure method

After the customer has entered his credit card data, the payment data is forwarded to the PayNow page, where the further payment processing takes place via 3D-Secure. The form details must be directly forwarded to the PayNow page and may not be transmitted to the merchant’s system! Also, no PCI-relevant data may be transmitted to the PayNow page as additional input parameters!

6 Batch processing via the interface

Basic information about using Batch files and about their structure can be found in the Batch Manager manual. Within batch processing not alle functions are available which are usually available for the online interface.

6.1 Batch calls and answers

This section describes the parameters which must be transferred within the data set (Record) for executing a credit card payment and which information can be found within the response file about the payment status.

Notice: Within Batch process not all functions of online interface are available.

For Batch calls there must be considered batch versions, from which optional parameters depend. All version designations starting with „2.“ pertain calls for a group of enterprises. That means within a batch file for a particular MerchantID can be transferred transactions for other merchants with a separate Sub-MID.

For the connections ECPCC, GMO, Kalixa and SafeCharge the possible actions are limited to Capture, Credit and Reverse.

Following table gives an overview of all batch versions that are possible for a specific action and their specialities:

Action	Version	Description
Authorize	1.2 / 2.2	with textfeld1, textfeld2, RTF, cardholder, transactionID, schemeReferenceID
	1.21 / 2.21	with textfeld1, textfeld2, RTF, approvalcode, cardholder, transactionID, schemeReferenceID
	1.3 / 2.3	with CVC, transactionID, schemeReferenceID
	1.5 / 2.5	with CVC, Zone
Capture	1.2 / 2.2	with textfeld1, textfeld2
	1.21 / 2.21	with textfeld1, textfeld2, approvalcode
	1.4 / 2.4	with stop of authorisation renewal (FinishAuth)
CaptureEx	1.3 / 2.3	with CVC
Credit	1.2 / 2.2	with textfeld1, textfeld2
	1.21 / 2.21	with textfeld1, textfeld2
	1.4 / 2.4	with stop of authorisation renewal (FinishAuth)
CreditEx	1.2 / 2.2	with textfeld1, textfeld2
	1.21 / 2.21	with textfeld1, textfeld2
	1.3 / 2.3	with textfeld1, textfeld2
Sale	1.2 / 2.2	with textfeld1, textfeld2, RTF, cardholder, transactionID, schemeReferenceID
	1.21 / 2.21	with textfeld1, textfeld2, RTF, approvalcode, cardholder, transactionID, schemeReferenceID
	1.3 / 2.3	with CVC, textfeld1, textfeld2, transactionID, schemeReferenceID
	1.5 / 2.5	with CVC, Zone
Reverse	1.x / 2.x	Standard version

Description of the possible batch versions

The structure for a credit card payment within a Batch file to be submitted is the following:

HEAD,<MerchantID>,<Date>,<Version>

CC,Authorize,<Amount>,<Currency>,<TransID>,(<RefNr>),<CCBrand>,<CCNr|PCNr>, [<CCCVC>,]<CCExpiry>,<OrderDesc>[,<textfeld1>,<textfeld2>,<RTF>,<approvalcode>,<cardholder>,<Zone>,<transactionID>,<schemeReferenceID>]

CC,Capture,<Amount>,<Currency>,<TransID>,(<RefNr>),<PayID>,[<FinishAuth,<textfeld1>,<textfeld2>,<approvalcode>]

CC,Sale,<Amount>,<Currency>,<TransID>,(<RefNr>),<CCBrand>,<CCNr|PCNr>, [<CCCVC>,]<CCExpiry>,<OrderDesc>[,<textfeld1>,<textfeld2>,<RTF>,<approvalcode>,<cardholder>,<Zone>,<transactionID>,<schemeReferenceID>]]

CC,Credit,<Amount>,<Currency>,<TransID>,(<RefNr>),<PayID>[,<FinishAuth>,<textfeld1>,<textfeld2>]

CC,CreditEx,<Amount>,<Currency>,<TransID>,(<RefNr>),<CCBrand>,<CCNr|PCNr>, [<CCCVC>,]<CCExpiry>,<OrderDesc>[,<textfeld1>,<textfeld2>]

CC,Reverse,<Amount>,<Currency>,<TransID>,(<RefNr>),<PayID>

FOOT,<CountRecords>,<SumAmount>

Example for batch versions:

Version 1.2:

CC,Sale,<Amount>,<Currency>,<TransID>,(<RefNr>),<CCBrand>,<CCNr|PCNr>,<CCExpiry>,<OrderDesc>

CC,Sale,<Amount>,<Currency>,<TransID>,(<RefNr>),<CCBrand>,<CCNr|PCNr>,<CCExpiry>,<OrderDesc>,<textfeld1>,<textfeld2>,<RTF>,<cardholder>,<transactionID>,<schemeReferenceID>

Version 1.21:

CC,Sale,<Amount>,<Currency>,<TransID>,(<RefNr>),<CCBrand>,<CCNr|PCNr>,<CCExpiry>,<OrderDesc>,<textfeld1>,<textfeld2>,<RTF>,<approvalcode>,<cardholder>,<transactionID>,<schemeReferenceID>

Version 1.3:

CC,Sale,<Amount>,<Currency>,<TransID>,(<RefNr>),<CCBrand>,<CCNr|PCNr>,<CCCVC>,<CCExpiry>,<OrderDesc>,<textfeld1>,<textfeld2>,<transactionID>,<schemeReferenceID>

Version 1.5:

HEAD,[Master]MerchantID,Date,2.x

Type,Action,[Slave]MID,Amount,Currency,TransID,Data (depends on Action)

FOOT,CountRecords,SumAmount

Example for Master MID Funktion:

HEAD,[Master]MerchantID,Date,2.x Type,Action,[Slave]MID,Amount,Currency,TransID,Data (depends on Action) FOOT,CountRecords,SumAmount

The following table describes the individual fields and values used within the data set (record) in the batch file:

Key	Format	CND	Description
Type	a..11	M	HEAD for Header, FOOT for Footer, CC for credit card
Action	a..20	M	The parameter Action defines the type of transaction: Authorize (authorisation) Capture Sale Credit CreditEx (credit note without previous capture; please agree this with First Cash Solution Support beforehand) Reverse (cancellation)
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 code, three digits DIN / ISO 4217, e.g. EUR, USD, GBP. Please find an overview here: Currency table
TransID	ans..64	M	TransactionID which should be unique for each payment. Please note for some connections the different formats that are given within the specific parameters.
RefNr	ns..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 First Cash Solution settlement file (CTSF) we cannot add the additional payment data. Only ASCII characters are allowed. Special characters such as (“umlauts”, …) are not permitted and may have to be replaced by ASCII characters (e.g. ü → ue, é → e, …).
PayID	an32	M	ID for this transaction assigned by the 1cs Online Payment System, e.g. for referencing in batch files as well as for capture or credit request.
OrderDesc	ans..127	O	Description of purchased goods, unit prices etc.
CCBrand	a..22	C	Credit card brand. Please note the spelling! According to table of credit card brands!
CCNr	n..16	C	Credit card number at least 12-digit, numerical without spaces. You can optionally transmit also a pseudo card number (PCN)
PCNr	n16	O	Pseudo Card Number: Random number generated by the 1cs OPS which represents a genuine credit card number. The pseudo card number (PCN) starts with 0 and the last 3 digits correspond to those of the real card number. You can use the PCN like a genuine card number for authorisation, capture and credits. PCNr is a response value from the 1cs OPS and is sent as CCNr in Request or part of card-JSON
CCCVC	n..4	O	Card verification number in Version 1.3: In the case of Visa and MasterCard the last 3 numbers on the signature strip of the credit card. 4 numbers in the case of American Express.
CCExpiry	n6	OC	Expiry date of the credit card in the format YYYYMM, e.g. 201707.
FinishAuth	ans1	O	Version=1.4: If using the authorisation renewal, cancel repeat with the value Y in the field FinishAuth in the case of Capture or Credit. Example: You capture a partial delivery. The rest of the order cannot be supplied. You therefore enter Y in the FinishAuth field for Part-capture so that the the 1cs Online Payment System does not authorise the remaining amount. Please note for this also the following section about Cancel authorisation renewals.

Description of fields within the record for Batch files

The record area within the response file for Batch transactions looks as follows:

HEAD,<MerchantID>,<Date>,<Version>

CC,Authorize,<Amount>,<Currency>,<TransID>,(<RefNr>),<PayID>,<CCBrand>,<CCNr|PCNr>,[<CCCVC>,]<CCExpiry>,<OrderDesc>[,<textfeld1>,<textfeld2>,<RTF>,<approvalcode>,<cardholder>,<Zone>,<transactionID>,<schemeReferenceID>],<Status>,<Code>

CC,Capture,<Amount>,<Currency>,<TransID>,(<RefNr>),<PayID>[<textfeld1>,<textfeld2>,<approvalcode>],<Status>,<Code>

CC,AuthSplit,<Amount>,<Currency>,<TransID>,(<RefNr>),<PayID>,FAILED,<Code>,<Description>,[<PCNr>]

CC,Renewal,<Amount>,<Currency>,<TransID>,(<RefNr>),<PayID>,FAILED,<Code>,<Description>,[<PCNr>]

CC,Sale,<Amount>,<Currency>,<TransID>,(<RefNr>),<PayID>,<CCBrand>,<CCNr|PCNr>,[<CCCVC>,]<CCExpiry>,<OrderDesc>[,<textfeld1>,<textfeld2>,<RTF>,<approvalcode>,<cardholder>,<Zone>,<transactionID>,<schemeReferenceID>],<Status>,<Code>

CC,Credit,<Amount>,<Currency>,<TransID>,(<RefNr>),<PayID>[,<FinishAuth>,<textfeld1>,<textfeld2>],<Status>,<Code>

CC,CreditEx,<Amount>,<Currency>,<TransID>,(<RefNr>),<CCBrand>,<CCNr|PCNr>,[<CCCVC>,]<CCExpiry>,<OrderDesc>[,<textfeld1>,<textfeld2>],<Status>,<Code>

CC,Reverse,<Amount>,<Currency>,<TransID>,(<RefNr>),<PayID>,<Status>,<Code>

FOOT,<CountRecords>,<SumAmount>

Example for batch versions:

Version 1.2:

CC,Sale,<Amount>,<Currency>,<TransID>,(<RefNr>),<CCBrand>,<CCNr|PCNr>,<CCExpiry>,<OrderDesc>,<Status>,<Code>

CC,Sale,<Amount>,<Currency>,<TransID>,(<RefNr>),<CCBrand>,<CCNr|PCNr>,<CCExpiry>,<OrderDesc>,<textfeld1>,<textfeld2>,<RTF>,<cardholder>,<transactionID>,<schemeReferenceID>,<Status>,<Code>

Version 1.21:

CC,Sale,<Amount>,<Currency>,<TransID>,(<RefNr>),<CCBrand>,<CCNr|PCNr>,<CCExpiry>,<OrderDesc>,<textfeld1>,<textfeld2>,<RTF>,<approvalcode>,<cardholder>,<transactionID>,<schemeReferenceID>,<Status>,<Code> Version 1.3: CC,Sale,<Amount>,<Currency>,<TransID>,(<RefNr>),<CCBrand>,<CCNr|PCNr>,<CCCVC>,<CCExpiry>,<OrderDesc>,<textfeld1>,<textfeld2>,<transactionID>,<schemeReferenceID>,<Status>,<Code> Version 1.5: CC,Sale,<Amount>,<Currency>,<TransID>,(<RefNr>),<CCBrand>,<CCNr|PCNr>,<CCCVC>,<CCExpiry>,<OrderDesc>,<Zone>,<Status>,<Code>

The following table describes the response parameters which the Batch Manager saves in the Record area for each transaction (standard parameters not explained here, such as <TransID> or <RefNR> and request parameters are returned unchanged and correspond to the call as specified before):

Key	Format	CND	Description
Action	a..20	M	The parameter Action defines the type of transaction like capture or credit – see above.
PayID	an32	M	ID for this transaction assigned by the 1cs Online Payment System, e.g. for referencing in batch files as well as for capture or credit request.
Status	a..50	M	OK or FAILED
Code	n8	M	Error code according to the 1cs Online Payment System Response Codes Excel file
PCNr	n..16	O	Pseudo Card Number: Random number generated by the 1cs OPS which represents a genuine credit card number. The pseudo card number (PCN) starts with 0 and the last 3 digits correspond to those of the real card number. The PCN can be used like a genuine card number for authorisation, capture and credits. PCNr is a response value from the 1cs Online Payment System and is sent as CCNr in Request or part of card-JSON

Description of result parameters within the record for Batch files

6.2 Cancel authorisation renewals

With a credit card authorisation you get the right to claim a payment. However an authorisation lasts only 30 days which is a problem if you capture a partial amount, for example as part payment for several partial shipments. In order to reproduce your payment request the 1cs Online Payment System can repeat an expired authorisation automatically.

If an order cannot be delivered or has been cancelled by the customer, it is very important that the automatic authorisations stop. Your customer’s card limit will be otherwise reduced permanently because the the 1cs Online Payment System continues to charge your customer’s card.

Under normal circumstances the the 1cs Online Payment System stops the automatic authorisation renewal when the authorised amount has been captured in full. In Batch version 1.4 you can also stop the authorisation renewal manually by changing the payment status. To perform this you submit a capture in your batch file whose amount is under the admissible limit. Since the 1cs Online Payment System refuses credit card captures below €1.00, the payment status changes to FAILED in the case of lesser amounts. the 1cs Online Payment System therefore renews this authorisation no further. A corresponding capture entry of €0.05 is shown for example as follows:

CC,Capture,5,EUR,BestNr.0815,Rg.Nr.5180,a86dga4310d24453acd6f8a3112a769,y

Since the amount of 5 cents lies below the minimum amount of €1.00, the 1cs Online Payment System refuses the capture with the error message MinValue. The payment status changes to FAILED and the authorisation renewal is stopped.

7 CAPN: American Express

7.1 Introduction

7.1.1 Acquirers and connection

The 1cs Online Payment System supports many different credit card connections to various acquirers / processors with different protocols.

You can find an overview of all different credit card interfaces here: Payments by Credit Card.

Additional features (e.g. AVS (Address Verification Service), refund, 3-D Secure, …) may depend on the specific integration and acquirer.

7.1.2 Integration with the 1cs Online Payment System

In general we offer two different ways of integration:

	Payment Page (payssl.asp	Direct integration (direct.aspx)
Credit card number (PAN) handling	irectly handled by payment page. Credit card number, expiry date, CVV, … are requested by the payment form You will not get in contact with PAN, so much easier PCI DSS compliance. You will receive optional a PseudoCardNumber (PcNr) as a 1cs OPS internal token to represent the PAN.	Your system handles PAN directly, therefore you have “full control”. As your system gets in contact with the credit card number (PAN) your system will be in fully PCI DSS focus.
3-D Secure handling	You only need to add KVP “MsgVer=2.0” to indicate that your system is ready for 3-D Secure 2.x The rest (redirect to issuer bank for consumer authentication) is handled by the 1cs OPS payment page.	You only need to add KVP “MsgVer=2.0” to indicate that your system is ready for 3-D Secure 2.x Your system has to consumer redirect to issuer bank in case of consumer authentication
Additional data	Additional data can be provided via additional JSON parameters, e.g.: “credentialOnFile” (for recurring payments) address data (for AVS) 3-D Secure policy data
Shop-/System integration	The payment page can be customized (logos, colors, positions, …) to match your corporate identify using templates which can be prepared by you. The consumer is *redirected* to the payment page to input credit card details (PAN, expiry date, CVV, …). Your shop is informed via the 1cs Online Payment System notify for result of payment process.	Your system has full control of the input fields for credit card details The consumer is not redirected and your system gets the result of API call via direct response values
Further actions	After initiating the payment process you may start further actions like capture or credit/refund, cancellations, … These actions refer to a previous payment process identified by a PayId – which is fully out of PCI DSS focus.
Conclusion	Recommended for standard integrations – due to easy integration and simplified compliance. The 1cs Online Payment System takes PAN handling for you → simplified PCI DSS handling. You can customize the 1cs OPS payment page using templates.	Recommended if you need full control and you do not want a redirect of the consumer. Your system will be in full PCI DSS scope.

The documentation below is therefore always devided into two sections:

integration via payment page (payment form)
- with common parameters to integrate the 1cs Online Payment System payment form
- with parameters to customize the payment form
- with specific parameters for the desired acquirer / processor
integration via Server-2-Server (direct) integration
- with common parameters to integrate the 1cs OPS payment form
- with specific parameters for the desired acquirer / processor

7.1.3 Implementation of 3-D Secure (2.x)

Common notes to 3-D Secure

3-D Secure is a process that authenticates the card holder to ensure that the consumer using the credit card data really is the card holder.

3-D Secure shall provide abuse of credit card data – specially in ecommerce environment.

3-D Secure 1.x has been implemented and asks the card holder typically for a password with each card usage.

3-D Secure 2.x has been implemented to:

enable strong customer authentication (SCA) by authenticate the card holder with 2 independent factors of these 3 factors:
- something the card holder knows, e.g. a password
- something the card holder owns, e.g. a device (like phone to receive a token via SMS or using other OTP, token generator, …)
- something the card holder is, e.g. biometrics (like finger print, face-id, …)
enable seemless authentication where the consumer is not authenticated and not asked to authenticate himself.

3-D Secure with the 1cs Online Payment System

Prepare yourself / your integration to be 3-D Secure 2.x ready – here a short overview with some technical details.

	3-D Secure 1.x	3-D Secure 2.x	3-D Secure 2.x Sample
Depend on your integration: Payment Form ./. Server-2-Server
Payment Page / Payment Form	Your existing integration.	Just add API parameter “MsgVer=2.0”, the rest is handled automatically by the 1cs Online Payment System	Add parameter “MsgVer=2.0” to your existing API call to start Payment Form.
URL-processing	URLFailure and URLSuccess work with http-GET	RLFailure and URLSuccess work with http-POST (due to amount of data). So pls. prepare to handle both (GET + POST)
Server-2-Server integration	Use KVP: CCNr: Credit card number (PAN) CCExpiry: Expiry date of the credit card CCCVC:Card verification number CCBrand: Credit card brand.	e “card“-JSON to provide card data to API	{ “securityCode”: “569”, “expiryDate”: “202508”, “cardholderName”: “William Thomas”, “number”: “4111111111111111”, “brand”: “VISA” } card=ewogICAgInNlY3VyaXR5Q29kZSI6ICI1NjkiLAogICAgImV4cGlyeURhdGUiOiAiMjAyNTA4IiwKICAgICJjYXJkaG9sZGVyTmFtZSI6ICJXaWxsaWFtIFRob21hcyIsCiAgICAibnVtYmVyIjogIjQxMTExMTExMTExMTExMTEiLAogICAgImJyYW5kIjogIlZJU0EiCn0=
For specific use cases, find other use cases here: 3DS 2.0 Merchant Use-Cases
Use Case	3-D Secure 1.x	3-D Secure 2.x	3-D Secure 2.x Sample
Recurring payments (initial)	Use parameter “RTF=I” you may receive TransactionID as Card scheme specific transaction ID	Change “RTF” to parameter “credentialOnFile“-JSON with “recurring” and “initial=true” you may receive schemeReferenceID as Card scheme specific transaction ID	e.g.: Recurring with initial = true The JSON needs to be base64-encoded and then used as value for parameter credentialOnFile (pls. be aware to use the full base64-encoded string, including “=” at the end) credentialOnFile=ewogICAgInR5cGUiOiB7CiAgICAgICAgInJlY3VycmluZyI6IHsKICAgICAgICAgICAgInJlY3VycmluZ0ZyZXF1ZW5jeSI6IDMwLAogICAgICAgICAgICAicmVjdXJyaW5nU3RhcnREYXRlIjogIjIwMjEtMDktMTQiLAogICAgICAgICAgICAicmVjdXJyaW5nRXhwaXJ5RGF0ZSI6ICIyMDIyLTA5LTE0IgogICAgICAgIH0KICAgIH0sCiAgICAiaW5pdGlhbFBheW1lbnQiOiB0cnVlCn0=
Recurring payments (subsequent)	Use parameter “RTF=R” and send TransactionID as Card scheme specific transaction ID	Change “RTF” to parameter “credentialOnFile“-JSON with “recurring” and “initial=false” and send schemeReferenceID as Card scheme specific transaction ID	e.g.: Recurring with initial = false After base64-encoding: credentialOnFile=ewogICAgInR5cGUiOiB7CiAgICAgICAgInJlY3VycmluZyI6IHsKICAgICAgICAgICAgInJlY3VycmluZ0ZyZXF1ZW5jeSI6IDMwLAogICAgICAgICAgICAicmVjdXJyaW5nU3RhcnREYXRlIjogIjIwMjEtMDktMTQiLAogICAgICAgICAgICAicmVjdXJyaW5nRXhwaXJ5RGF0ZSI6ICIyMDIyLTA5LTE0IgogICAgICAgIH0KICAgIH0sCiAgICAiaW5pdGlhbFBheW1lbnQiOiBmYWxzZQp9
Customer Initiated (initial)	Use parameter “RTF=E” you may receive TransactionID as Card scheme specific transaction ID	Change “RTF” to parameter “credentialOnFile“-JSON with “CIT” and “initial=true” you may receive schemeReferenceID as Card scheme specific transaction ID	e.g.: CIT (CustomerInitiated) with initial = true After base64-encoding (again: don’t miss “=” at the end; it has to be part of the value): credentialOnFile=ewogICAgInR5cGUiOiB7CiAgICAgICAgInVuc2NoZWR1bGVkIjogIkNJVCIKICAgIH0sCiAgICAiaW5pdGlhbFBheW1lbnQiOiB0cnVlCn0=
Merchant Initiated (subsequent)	Use parameter “RTF=M” and send TransactionID as Card scheme specific transaction ID	Change “RTF” to parameter “credentialOnFile“-JSON with “MIT” and “initial=false” and send schemeReferenceID as Card scheme specific transaction ID	e.g. MIT (MerchantInitiated) with initial = false After base64-encoding: credentialOnFile=ewogICAgInR5cGUiOiB7CiAgICAgICAgInVuc2NoZWR1bGVkIjogIk1JVCIKICAgIH0sCiAgICAiaW5pdGlhbFBheW1lbnQiOiBmYWxzZQp9
ation Service (AVS) (depending on acquirer / processor)	Use parameter AddrStreet AddrStreetNr AddrZip AddrCity ….	Change address data to “address“-JSON	e.g. Put address data into JSON structure billingAddress=ewogICAgImNpdHkiOiAiTmV3IFlvcmsiLAogICAgImNvdW50cnkiOiB7CiAgICAgICAgImNvdW50cnlBMyI6ICJVU0EiCiAgICB9LAogICAgImFkZHJlc3NMaW5lMSI6IHsKICAgICAgICAic3RyZWV0IjogIlBhcmsgQXZlbnVlIiwKICAgICAgICAic3RyZWV0TnVtYmVyIjogIjI3MCIKICAgIH0sCiAgICAicG9zdGFsQ29kZSI6ICIxMDAxNy0yMDcwIiwKICAgICJzdGF0ZSI6ICJOWSIKfQ==
Apply for frictionless payment processing	not supported with 3-D Secure 1.x each payment will be authenticated	Provide additional data as JSON-KVP: JSON Objects	e.g. Explicitly apply for customer challenge After base64-encoding (again: don’t miss “=” at the end; it has to be part of the value): threeDSPolicy=ewogICAgImNoYWxsZW5nZVByZWZlcmVuY2UgIjogIm1hbmRhdGVDaGFsbGVuZ2UiCn0=

7.2 Specific parameters for CAPN: American Express

Besides the general parameters described below for the credit card connection, CAPN requires the following additional parameters. An authorisation with 3-D Secure is possible.

Notice: For security reasons, the 1cs OPS rejects all payment requests with formatting errors. Therefore, please use the correct data type for each parameter.

The following table describes the additional encrypted payment request parameters described below for “interface via form” and “interface via Server-to-Server” :

Paramter	Format	CND	Description
RefNr	ns..30	M	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 1cs OPS settlement file (CTSF) we cannot add the additional payment data. Note: RefNr has different format restrictions depending on the AMEX EPA/settlement file: CAPN –> AMEX GRRCN EPA = 30-characters alphanumeric Note: Please note that AMEX reference numbers can only be reported in GRRCN format accounting files. With CAPN, EPA files do not receive any references for assignment. Details on the EPA-format are provided to you by your acquirer. Only ASCII characters are allowed. Special characters such as (“umlauts”, …) are not permitted and may have to be replaced by ASCII characters (e.g. ü → ue, é → e, …).
OrderDesc	ans..768	M	Description of purchased goods, unit prices etc.
AmountAuth	n..10	O	Prepaid card: Actually authorised amount in the smallest currency unit. Please contact 1cs Helpdesk as this function must also be activated at the 1cs OPS.
ContractID	n..8	O	Further reference which can be used to retrieve the combination TerminalID/Contract partner number
			Contact data/Address verification (AVS)
FirstName	ans..15	O	First name of the customer (for AVS)
LastName	ans..30	O	Last name of the customer (for AVS)
AddrStreet	ans..20	O	Street name and street number, e.g. 18850~N~56~ST~#301 (for AVS)
AddrZip	n..9	O	Postcode (for AVS)
eMail	ans..60	O	Email address of the customer (for AVS)
Phone	n..10	O	Phone number of the customer: for countries which do not use this system, please send the last 10 digits (for AVS)
sdFirstName	ans..15	O	First name in the delivery address (for AVS)
sdLastName	ans..30	O	Last name in the delivery address (for AVS)
sdStreet	ans..50	O	Street name and street number in th delivery address, e.g. 4102~N~289~ST~#301 (for AVS)
sdZip	n..9	O	Postcode in the delivery address
sdCountryCode	n3	O	Country code of the delivery address according to ISO-3166-1 numeric (3-digits) (for AVS)
sdPhone	ans..10	O	Phone number in the delivery address: for countries which do not use this system, please send the last 10 digits (for AVS)

Additional parameters for the credit card payments

The following table describes the result parameters with which the 1cs OPS responds to your system.

these result parameters are additional to the standard parameters for “interface via form” and “interface via Server-to-Server” described below

pls. be prepared to receive additional parameters at any time and do not check the order of parameters

the key (e.g. MerchantId, RefNr) should not be checked case-sentive

Key	Format	CND	Description
RefNr	ns..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 the 1cs OPS settlement file (CTSF) we cannot add the additional payment data. Only ASCII characters are allowed. Special characters such as (“umlauts”, …) are not permitted and may have to be replaced by ASCII characters (e.g. ü → ue, é → e, …).
CodeExt	n..10	O	Error code from CAPN, if agreed with support@1cs.de
ApprovalCode	n..6	O	Approval code of the transaction
TransactionID	ans..48	O	Transaction ID from CAPN
AmountAuth	n..10	M	Authorised amount in the smallest currency unit. For prepaid cards this can be less than the initially requested amount.
Match	a1	O	Total result of address check (American Express via CAPN): For possible values see A3 AVS match parameters
cvcmatch	a1	C	Result of CVC check. Possible values: M = Match, N = No match, U = Issuer unable to process request
PAR	ans..999	O	Payment Account Reference data provided mainly by VISA/MC or AMEX, which is a non-financial reference number assigned to each unique Primary Account Number (PAN) and mapped to all its affiliated payment tokens.

Additional response parameters for credit card payments

Name	Anbieter	Zweck	Ablauf
cookie_status	www.firstcashsolution.de	Speichert Ihren Zustimmungsstatus für Cookies auf der aktuellen Domäne.	1 Jahr
pll_language	www.firstcashsolution.de	Speichert Ihre Spracheinstellungen.	1 Jahr
PHPSESSID	www.firstcashsolution.de	In diesem Cookie wird die Session-ID, also eine zufällig generierte Identifikationsnummer für Ihre Sitzung, gespeichert. Dieser Cookie wird – abhängig von Ihrer Browser-Einstellung – beim Schließen eines Tabs oder Fensters, das diesen Cookie gesetzt hat, gelöscht. Dadurch ist es zum Beispiel möglich, zuvor bereits ausgefüllte Felder eines Formulars vom Browser automatisch eintragen zu lassen.	Session
wordpress_test_cookie	www.firstcashsolution.de	Prüft ob Cookies gesetzt werden können	1 Jahr
pum-*	www.firstcashsolution.de	Speichert die Information welches PopUp geschlossen wurde	1 Monat