All supported POST parameters for CopyandPay and WPF

Follow

This section gives an overview of all available POST parameters.


 

Header

The header group of the HTTPS Post parameters holds transmission and security related information.

Request
REQUEST.VERSION=1.0
SECURITY.SENDER=123a456b789c123d456e789f012g345
Response
RESPONSE.VERSION=1.0
SECURITY.SENDER=123a456b789c123d456e789f012g345

 


 

Transactions data group examples

For a comprehensive overview about all parameters and their descriptions please have a look at the Transaction Data Groups chapter.

 

Transaction Group

The Transaction group contains all information required to process a transaction.

Transaction Group
TRANSACTION.MODE=LIVE
TRANSACTION.RESPONSE=SYNC
TRANSACTION.CHANNEL=546a456b789c123d456e789f012g821

 


 

User Group

The User group contains the information about the user sending the request.

User Group
USER.LOGIN=12343214123432141234321412343214
USER.PWD=geheim

 


 

Identification Group

The Identification group contains all IDs which are used for the identification of the transaction:

  • IDENTIFICATION.TRANSACTIONID
  • IDENTIFICATION.UNIQUEID
  • IDENTIFICATION.SHORTID
  • IDENTIFICATION.REFERENCEID
  • IDENTIFICATION.SHOPPERID
  • IDENTIFICATION.INVOICEID

In the request the merchant can provide a Transaction ID for own matching purposes.

For transaction types which require a reference to a former transaction (e.g. Capture, Reversal, Refund) a Reference ID has to be provided.

The Shopper ID is used to group transactions of a certain shopper.

Request
IDENTIFICATION.TRANSACTIONID=MerchantAssignedID
IDENTIFICATION.REFERENCEID=r123i654j321k098l765m432n21e456
IDENTIFICATION.SHOPPERID=shopper000321

During processing the system generates a universal unique ID. This Unique ID must be used for all automated matching and search purposes. The Reference ID therefore is the Unique ID of the transaction-to-be-referenced.

To provide an ID which is shorter and easier to enter manually, the Short ID is provided. The Short ID is used for the descriptor of the transaction and to search manually for transactions in the business intelligence platform. The Short ID doesn’t guarantee universal uniqueness, however the probability for non-uniqueness (especially in the context it appears) is very low.

Response
IDENTIFICATION.TRANSACTIONID=MerchantAssignedID
IDENTIFICATION.UNIQUEID=h987i654j321k098l765m432n210o987
IDENTIFICATION.SHORTID=1234.5678.9876
IDENTIFICATION.REFERENCEID=r123i654j321k098l765m432n21e456
IDENTIFICATION.SHOPPERID=shopper000321

 


 

Payment Group

The Payment group determines which payment method and type to use and provides all monetary payment details of the transaction. Furthermore, it contains the description of the transaction by means of the USAGE and DESCRIPTOR parameters.

Payment Group
PAYMENT.CODE=DD.DB

If you want to use certain payment methods, please ensure that the applied Channel ID has been activated for these payment methods. Depending on the chosen payment method, there are specific types available. A detailed description of the payment types can be found in the Payment Typesdescription.

In the request the Payment group must include the Presentation tag while the response gives back the Presentation tag as well as the Clearing tag. The Clearing tag contains all data as the end customer obtains it on his credit card or bank statement.

Request
PAYMENT.CODE=DD.DB
 
PRESENTATION.AMOUNT=1.00
PRESENTATION.CURRENCY=EUR
PRESENTATION.USAGE=Order Number 1234
Response
PAYMENT.CODE=DD.DB
 
PRESENTATION.AMOUNT=1.00
PRESENTATION.CURRENCY=EUR
PRESENTATION.USAGE=Order Number 1234
 
CLEARING.AMOUNT=1.00
CLEARING.CURRENCY=EUR
CLEARING.DESCRIPTOR=1234.1234.1234 - Order Number 1234
CLEARING.BANKNAME=Royal Bank of Scottland
CLEARING.FXRATE=0.500000
CLEARING.FXSOURCE=FTX
CLEARING.FXDATE=2003-02-12

 


 

Account Group

The Account group holds all information regarding a credit card or bank account. Many parameters depend on the chosen payment method.

The credit card account tag looks like this:

Credit Card
ACCOUNT.NUMBER=4200000000000000
ACCOUNT.BRAND=VISA
ACCOUNT.EXPIRY_MONTH=09
ACCOUNT.EXPIRY_YEAR=2005
ACCOUNT.VERIFICATION=123

An example for a direct debit account tag group is shown here:

Direct Debit
ACCOUNT.HOLDER=Joe Doe
ACCOUNT.NUMBER=618495000
ACCOUNT.BANK=70070024
ACCOUNT.COUNTRY=DE

And SEPA direct debit account tag looks like this:

Direct Debit SEPA
ACCOUNT.HOLDER=Joe Doe
ACCOUNT.IBAN=DE64700700240618495000
ACCOUNT.BIC=DEUTDEDBMUC
ACCOUNT.COUNTRY=DE

The Online Transfer account tag looks like this:

Online Transfer
ACCOUNT.COUNTRY=DE

 


 

Customer Group

The customer group contains all customer specific information like name, address and contact details. The NAME and ADDRESS group are used basically for risk management purposes while the CONTACT group is important for callback validations and transmission of the mandate templates for direct debit countries which require a written confirmation.

The Customer group contains very specific customer information, which is necessary for some advanced risk management checks or dedicated direct debit schemes (e.g. “domiciliation bancaria” in Spain).

Customer Group
NAME.SALUTATION=Mr
NAME.TITLE=Dr
NAME.GIVEN=Joe
NAME.FAMILY=Doe
NAME.COMPANY=SampleCompany
 
ADDRESS.STREET=Leopoldstr. 1
ADDRESS.ZIP=80798
ADDRESS.CITY=München
ADDRESS.STATE=BY
ADDRESS.COUNTRY=DE
 
CONTACT.PHONE=+49-89-1234566
CONTACT.MOBILE=+49-172-1234566
CONTACT.EMAIL=info@provider.com
CONTACT.IP=123.123.123.123
 
CUSTOMER.IDENTIFICATION.PAPER=PASSPORT
CUSTOMER.IDENTIFICATION.VALUE=D00143434

 


 

MarketData Group

Merchants who want to process transactions containing flight ticket information can do this by using MarketData in settlement requests, i.e. in requests with transaction type DB or CP. The data that is mandatory for a valid request depends on the receiver connector, so please contact Peach Payments support for more specific information.

As described below, most of the fields have to be filled with standardized IATA-codes. The system will only do a plausibility-check on these fields, so please remember to check the receiver’s settlement responses, which might be file-based in some cases.

If you look at the example below, you will find that are several groups of “PASSENGER”-keys and “FLIGHT_LEG”-keys, each with a number at the end. This is because an Airline-Transaction can have more than one passenger and each passenger can have more than one flight-leg. Therefore the tailing numbers denote the position in the list.

Airline Example
MARKETDATA.TYPE= Airline
 
MARKETDATA.PASSENGER1.NAME=Hansa Bytt
MARKETDATA.PASSENGER1.ORIGINATING_AIRPORT=MUC
MARKETDATA.PASSENGER1.RESTRICTED_TICKET=false
MARKETDATA.PASSENGER1.TICKET_NUMBER=Ticket-312512
 
MARKETDATA.PASSENGER1.AGENT_CODE=12345678
MARKETDATA.PASSENGER1.AGENT_NAME=Travel With Us AG
MARKETDATA.PASSENGER1.AIRLINE_CODE=LHA
MARKETDATA.PASSENGER1.AIRLINE_NAME=Lufthansa
 
MARKETDATA.PASSENGER1.FLIGHT_LEG1.NUMBER=1
MARKETDATA.PASSENGER1.FLIGHT_LEG1.CARRIER_CODE=LHA
MARKETDATA.PASSENGER1.FLIGHT_LEG1.CLASS_OF_SERVICE=H
MARKETDATA.PASSENGER1.FLIGHT_LEG1.DESTINATION=VIE
MARKETDATA.PASSENGER1.FLIGHT_LEG1.FLIGHT_NUMBER=LH2332
 
MARKETDATA.PASSENGER1.FLIGHT_LEG1.NUMBER=2
MARKETDATA.PASSENGER1.FLIGHT_LEG2.CARRIER_CODE=OS
MARKETDATA.PASSENGER1.FLIGHT_LEG2.CLASS_OF_SERVICE=H
MARKETDATA.PASSENGER1.FLIGHT_LEG2.DESTINATION=BEG
MARKETDATA.PASSENGER1.FLIGHT_LEG2.FLIGHT_NUMBER=OS737
 
MARKETDATA.PASSENGER2.NAME=Kama Lytt
MARKETDATA.PASSENGER2.ORIGINATING_AIRPORT=MUC
MARKETDATA.PASSENGER2.RESTRICTED_TICKET=false
MARKETDATA.PASSENGER2.TICKET_NUMBER=Ticket-312513
 
MARKETDATA.PASSENGER2.AGENT_CODE=12345678
MARKETDATA.PASSENGER2.AGENT_NAME=Travel With Us AG
MARKETDATA.PASSENGER2.AIRLINE_CODE=LHA
MARKETDATA.PASSENGER2.AIRLINE_NAME=Lufthansa
 
MARKETDATA.PASSENGER1.FLIGHT_LEG1.NUMBER=1
MARKETDATA.PASSENGER2.FLIGHT_LEG1.CARRIER_CODE=LHA
MARKETDATA.PASSENGER2.FLIGHT_LEG1.CLASS_OF_SERVICE=G
MARKETDATA.PASSENGER2.FLIGHT_LEG1.DESTINATION=BEG
MARKETDATA.PASSENGER2.FLIGHT_LEG1.FLIGHT_NUMBER=LH1722

 


 

Recurrence Group (Manual Recurrence)

Recurring transactions are flagged with the RECURRENCE parameter. For an initial transaction (containing the CVV code) the following parameter needs to be submitted:

RECURRENCE.MODE=INITIAL

All recurring transactions (without a CVV code) need to be submitted with the REPEATED parameter:

RECURRENCE.MODE=REPEATED

 


 

Criterion Group

The Criterion group allows to add additional customized attributes which are not available by the standard set of HTTPS Post parameters to the transaction.

With the help of these freely definable ‘Criteria’ e.g. a customised statistics and analysis can be performed over all the transactions which have these parameters included. Furthermore, the Criterions can be used to store all kinds of information within the transaction for various purposes such as an automated or manual export and further processing of the information in third party systems.

Possible examples are the turnover of different affiliates, age groups or any other imaginable value or subdivision which should be available in the analysis front-end later on.

Criterion Group
CRITERION.Affiliate=ExternalShopXY
CRITERION.Age=30-40
CRITERION.known=yes
CRITERION.CustomerID=1234567

An example for the storage of information would be to submit e.g. an external customer ID or a special token for external matching purposes as a Criterion.

 


 

Authentication Group

This group allows the merchant to submit any kind of authentication information that authenticates the transaction itself (such as 3D Secure, SMS-identification and the like). Currently, this group is used to submit authentication information gathered from a Verified by Visa (VbV) or MasterCard Secure Code (MSC) request performed by a merchant himself. 

 

Authentication Group

AUTHENTICATION.TYPE=3DSecure
AUTHENTICATION.RESULT_INDICATOR=05
AUTHENTICATION.PARAMETER.VERIFICATION_ID=AAACAgSRBklmQCFgMpEGAAAAAAA
AUTHENTICATION.PARAMETER.VERIFICATION_ TYPE=2
AUTHENTICATION.PARAMETER.XID=CAACCVVUlwCXUyhQNlSXAAAAAAA

 


 

Processing Group

The Processing group contains a summary of the result of the entire processing. The structure of the status and reason codes is hierarchical while the return code is an independent, internal value which is used for very specific return messages. Any merchant side matching should be performed on the processing code or status and reason codes only, but not on the respective messages associated to these statuses.

Processing Group
PROCESSING.CODE=DD.DB.90.00
PROCESSING.TIMESTAMP=2003-02-12 14:58:07
PROCESSING.RESULT=ACK
PROCESSING.STATUS.CODE=90
PROCESSING.STATUS=NEW
PROCESSING.CONFIRMATON_STATUS=CONFIRMED
PROCESSING.REASON.CODE=00
PROCESSING.REASON=Successful Processing
PROCESSING.RETURN.CODE=000.000.000
PROCESSING.RETURN=Transaction succeeded
PROCESSING.RISK_SCORE=-20

The result derives from the status of the transaction, which means that a transaction which has the status REJECTED or FAILED has the result NOK, while all other statuses result in an ACK. For each status there are one or several reasons.

 


 

Asynchronous Response Processing Group

For asynchronous response messages additional parameters are part of the response message that contain the redirect information for the merchant.

Asynchronous Response Processing Group
PROCESSING.REDIRECT.URL=https://www.mybank.com/3D_validation
PROCESSING.REDIRECT.PARAM.TermUrl=https://terminalurl.org/payment/3D_response
PROCESSING.REDIRECT.PARAM.PAReq=m123n456o789p876q543r22323145346576
PROCESSING.REDIRECT.PARAM.MD=24358432975908324758904327589434

Depending on the type of the asynchronous process (i.e. Online Bank Transfer, Verified By Visa, MasterCard Securecode, …) the Redirect group contains a number of different parameters. Typically, the merchant redirects the shopper’s browser to the PROCESSING.REDIRECT_URL and passes the other parameters in this subgroup as parameters to the PROCESSING.REDIRECT_URL.

Please have a look at the Asynchronous Workflow description how these parameters must be processed by the merchant to fulfill the workflow requirements of the asynchronous process.

Note

Please be aware that not all asynchronous processes can fully be covered with the POST Transaction integration. Most of them are only possible with the XML API. Please contact Peach Payment support for more information.

 


 

Connector Group

Within the Connector group information about the connector which was selected for processing of the transaction is given back. This is especially used in conjunction with Prepayment (PP) or Invoice (IV) transactions where the end customer needs to know which bank account he has to direct his payment to. Furthermore, it is necessary to identify the receiving bank account in the context of mandate registrations (DD.RG).

Connector Group
CONNECTOR.ACCOUNT.HOLDER=Internal Account Holder
CONNECTOR.ACCOUNT.NUMBER=618495000
CONNECTOR.ACCOUNT.BANK=70070024
CONNECTOR.ACCOUNT.IBAN=DE82700202700666898869
CONNECTOR.ACCOUNT.BIC=HYVEDEMM
CONNECTOR.ACCOUNT.COUNTRY=DE

 


 

Frontend Group - Web Payment Frontend and 3D Secure Processes

When the POST integration is used in conjunction with the Web Payment Frontend (WPF) a number of optional parameters can be added to steer the appearance of the WPF pages. Most of these parameters override the default settings which have been made in the Business Intelligence Platform (BIP) and are therefore optional. Contrary to the standard POST Parameter integration the response to the request is not the payment result but a URL to start the WPF process. In case the “FRONTENT.ENABLED” parameter is set to true, the initial request is something like an authentication request to securely retrieve the URL to start WPF. The second response parameter POST.VALIDATION gives information if the request was successful or a validation error occurred.

Request
FRONTEND.ENABLED=true
FRONTEND.SESSION_ID=112j45lkjsd90a8ur342j5098uf09vfug43jfmalefj
FRONTEND.MODE=DEFAULT
FRONTEND.ONEPAGE=true
FRONTEND.POPUP=true
FRONTEND.LANGUAGE=en
Immediate Synchronous Response
Asynchronous Response after the end user has submitted his payment details
RESPONSE.VERSION=1.0
SECURITY.SENDER=123a456b789c123d456e789f012g345
TRANSACTION.MODE=LIVE
TRANSACTION.RESPONSE=SYNC
TRANSACTION.CHANNEL=9876.5432.1023
 
IDENTIFICATION.TRANSACTIONID=MerchantAssignedID
IDENTIFICATION.UNIQUEID=h987i654j321k098l765m432n210o987
IDENTIFICATION.SHORTID=1234.5678.9876
 
PROCESSING.CODE=DD.DB.90.00
PROCESSING.TIMESTAMP=2003-02-12 14:58:07
PROCESSING.RESULT=ACK
PROCESSING.STATUS.CODE=90
PROCESSING.STATUS=NEW
PROCESSING.REASON.CODE=00
PROCESSING.REASON=Successful Processing
PROCESSING.RETURN.CODE=000.000.000
PROCESSING.RETURN=Transaction succeeded
 
PAYMENT.CODE=DD.DB
PRESENTATION.AMOUNT=1.00
PRESENTATION.CURRENCY=EUR
PRESENTATION.USAGE=Order Number 1234
CLEARING.AMOUNT=1.00
CLEARING.CURRENCY=EUR
CLEARING.DESCRIPTOR=1234.1234.1234 - Order Number 1234
 
SECURITY.HASH=2d0ec783cb7c2d5b117499e6211caef4

 

Have more questions? Submit a request

Comments

Powered by Zendesk