1.1.2. Account Verification

Account verification transaction diagram

The Merchant should use Payneteasy API as described in General Account verification Process Flow.

Merchant -> "Payneteasy": Account verification request activate "Payneteasy" "Payneteasy" --> Merchant: Order ID "Payneteasy" -> Acquirer: Process Account verification activate Acquirer Merchant -> "Payneteasy": Get status by Order ID Acquirer --> "Payneteasy": Processing result deactivate Acquirer "Payneteasy" --> Merchant: Final status deactivate "Payneteasy"

Account verification request Customer checks out the order and Merchant sends Account verification request to Payneteasy server with specified parameters described in Account verification Request Parameters.
Order Id Payneteasy server sends back the response with orderid. Merchant shows the customer a message like Your order is being processed. Please, wait... and starts polling for status with given orderid as described in Order status asynchronous call.
Process Account verification Payneteasy server forwards Account verification request to bank acquirer asynchronously. The bank starts processing the transaction.
Get status by Order Id Merchant is polling for status with given orderid as described in Order status asynchronous call.
Processing result The bank responds to Payneteasy server with approve or decline for requested Account verification.
Final status Payneteasy server returns status to Merchant through Order status asynchronous call.

Process Account verification transaction

For integration purposes use staging environment sandbox.payneteasy.eu instead of production gate.payneteasy.eu. Account verification transactions are initiated through HTTPS POST request by using URL in the following format:

Account verification transaction by ENDPOINTID

The End point ID is an entry point for incoming Merchant`s transactions for single currency integration.

https://gate.payneteasy.eu/paynet/api/v2/account-verification/ENDPOINTID for account verification transaction

Account verification Request Parameters

In order to initiate a Account verification transaction Merchant sends an HTTPS POST request with the parameters specified in Account verification Request Parameters Table below

Account verification Request Parameters Length/Type Comment Necessity*
client_orderid 128/String Merchant order identifier Mandatory
order_desc 64k/String Brief order description Mandatory
card_printed_name 128/String Card printed name Mandatory
first_name 50/String Customer’s first name Optional
last_name 50/String Customer’s last name Optional
cardrefid 50/String Previously created tokenized card reference. It can be sent instead of cardholder data (credit_card_number, card_printed_name, expire_month, expire_year). cvv2 parameter necessity depends on the acquiring channel and necessity of it must be clarified with Tech Support. If cardrefid is used, other customer data (address1, first_name, last_name, etc.) can be skipped in the request - it will be gathered from the tokenized transaction. If customer data is sent in request with cardrefid, it will overwrite the data from the tokenized transaction for this request. The following parameters remain mandatory for request with cardrefid: email, ipaddress, client_orderid, order_desc, control Optional
ssn 32/Numeric Last four digits of the customer’s social security number Optional
birthday 8/Numeric Customer’s date of birth, in the format YYYYMMDD Optional
address1 50/String Customer’s address line 1 Optional if cardrefid is sent
city 50/String Customer’s city Optional if cardrefid is sent
state 2-3/String Customer’s state . Please see Reference for a list of valid state codes. Mandatory for USA, Canada and Australia Optional if cardrefid is sent
zip_code 10/String Customer’s ZIP code Optional if cardrefid is sent
country 2/String Customer’s country(two-letter country code). Please see Reference for a list of valid country codes Optional if cardrefid is sent
phone 15/String Customer’™s full international phone number, including country code Optional
cell_phone 15/String Customer’s full international cell phone number, including country code Optional
email 50/String Customer’s email address Mandatory
credit_card_number 20/Numeric Customer’s credit card number Mandatory
expire_month 2/Numeric Credit card expiration month Mandatory
expire_year 4/Numeric Credit card expiration year Mandatory
cvv2 3-4/Numeric Customer’s CVV2 code. CVV2 (Card Verification Value) is a three- or four-digit number AFTER the credit card number in the signature area of the card Mandatory
ipaddress 45/String Customer’s IP address, included for fraud screening purposes Mandatory
site_url 128/String URL the original Account verification is made from Optional
purpose 128/String Destination to where the payment goes. It is useful for the merchants who let their clients to transfer money from a credit card to some type of client’s account, e.g. game or mobile phone account. Sample values are: +7123456789; gamer0001@ereality.com etc. This value will be used by fraud monitoring system Optional
control 40/String Checksum generated by SHA-1. See Request authorization through control parameter for more details Mandatory
server_callback_url 128/String URL the transaction result will be sent to. Merchant may use this URL for custom processing of the transaction completion, e.g. to collect Account verifications data in Merchant’s database. See more details at Merchant Callbacks Optional
* acquirer can redefine the necessity of some fields so they become mandatory instead of optional
** leading and trailing whitespace in input parameters will be omitted

Please note the following characters must be escaped in the parameter values: & + “.

Account verification Request Example

client_orderid=902B4FF5
&order_desc=Test Order Description
&first_name=John
&last_name=Smith
&ssn=1267
&birthday=19820115
&address1=100 Main st
&city=Seattle
&state=WA
&zip_code=98102
&country=US
&phone=%2B12063582043
&cell_phone=%2B19023384543
&email=john.smith@gmail.com
&ipaddress=65.153.12.232
&site_url=www.google.com
&credit_card_number=4538977399606732
&card_printed_name=CARD HOLDER
&expire_month=12
&expire_year=2099
&cvv2=123
&purpose=user_account1
&server_callback_url=https://httpstat.us/200
&merchant_data=VIP customer
&control=768eb8162fc361a3e14150ec46e9a6dd8fbfa483

Account verification Response

All parameters in response are encoded in application/x-www-form-urlencoded MIME format

Account verification Response Parameter Description
type The type of response. May be async-response, validation-error, error. If type equals validation-error or error, error-message and error-code parameters contain error details
paynet-order-id Order id assigned to the order by Payneteasy
merchant-order-id Merchant order id
serial-number Unique number assigned by Payneteasy server to particular request from the Merchant.
error-message If status is error this parameter contains the reason for decline or error details
error-code The error code is case of error status

Account verification Response Example

type=async-response
&serial-number=00000000-0000-0000-0000-0000000624e8
&merchant-order-id=59e1e3ca-5d44-11e1-b3d6-002522b853b4
&paynet-order-id=94935

Account verification Postman Collection

Account verification Request Debug

endpointid input your ENDPOINTID
client_orderid make it or use your internal invoice ID
order_desc
cardrefid
first_name
last_name
ssn
birthday
address1
city
state
zip_code
country
phone
cell_phone
email
ipaddress
site_url
credit_card_number enter the beginning of the sequence, and then "i"
card_printed_name
expire_month
expire_year
cvv2
purpose
merchant_control input your Control Key
server_callback_url
merchant_data

String to sign
Signature

Server callback result

Upon completion by the System it returns the result on the specified server_callback_url with the following parameters described in Account verification, Return Callback Parameters
The checksum is used to ensure that the callback is initiated for a particular Merchant, and not for anybody else claiming to be such Merchant. This SHA-1 checksum, the control parameter, is created by concatenation of the parameters values in the following order:
  • status
  • orderid
  • client_orderid
  • merchant_control

A complete string example may look as follows:

approvedS279G323P4T1209294c258d6536ababe653E8E45B5-7682-42D8-6ECC-FB794F6B11B1

Encrypt the string using SHA-1 algorithm. The resultant string yields the control parameter. For the above-mentioned example the control will take the following value:

e04bd50531f45f9fc76917ac78a82f3efaf0049c

All parameters are sent via GET method.

Server callback result example

status=declined
&error-message=Decline, refer to card issuer
&error-code=107
&paynet-order-id=S279G323P4T1209294
&merchant-order-id=c258d6536ababe65

Account verification form diagram

Account verification form integration is relevant for merchants who are not able to accept customer card details. All this stuff is completely implemented on the Payneteasy gateway side. The merchant may customize the look and feel of the Account verification form.

Customer -> Merchant: Checkout activate Merchant Merchant -> "Payneteasy": account-verification-form/ENDPOINTID activate "Payneteasy" "Payneteasy" --> Merchant: status=processing deactivate "Payneteasy" deactivate Merchant Customer -> Customer: Input cardholder data Customer -> "Payneteasy": Submit form activate "Payneteasy" "Payneteasy" -> "Payneteasy": Processing "Payneteasy" --> Customer: Redirect to **redirect_url** deactivate "Payneteasy" Customer -> Merchant: Return to the Shop alt status loop Merchant -> "Payneteasy": status/ENDPOINTID activate "Payneteasy" "Payneteasy" --> Merchant: status=processing deactivate "Payneteasy" end else callback ... transaction processing ... "Payneteasy" --> Merchant: Callback notification end

Checkout – Customer proceeds to verification.
Merchant sends Account verification form HTTPS POST request to Payneteasy server with specified parameters described in Account verification form Request Parameters.
Payneteasy gateway returns response which contains an additional parameter redirect-url. This is the URL where merchant must redirect Customer’s browser to.
See details about response format in Account verification form Response.
Merchant sends HTTP 302 redirect to Customer’s browser using URL which is obtained from the redirect-url response parameter.
Customer fills in payment details and submits the Account verification form.
When verification is completed Payneteasy gateway redirects the Customer’s browser to redirect_url request parameter provided by merchant in the original request accomplished at step 2. See details in Account verification form final redirect.

Process Account verification form transaction

For integration purposes use staging environment sandbox.payneteasy.eu instead of production gate.payneteasy.eu. Account verification form transactions are initiated through HTTPS POST request by using URL in the following format:

Account verification form transaction by ENDPOINTID

The End point ID is an entry point for incoming Merchant`s transactions for single currency integration.

https://gate.payneteasy.eu/paynet/api/v2/account-verification-form/ENDPOINTID for account verification form transaction

Account verification form fields

This form contains the following fields:

Form field name Description
credit_card_number Customer’s credit card number 4455555555555544

Initiating verification with account verification form

Merchant must supply the following parameters to initiate a verification using Account verification form template.

Account verification form Request Parameters

Request parameter name Length/Type Comment Necessity*
client_orderid 128/String Merchant order identifier Mandatory
order_desc 64k/String Brief order description Mandatory
first_name 50/String Customer’s first name Mandatory
last_name 50/String Customer’s last name Mandatory
ssn 4/Numeric Last four digits of the customer’s social security number Optional
birthday 8/Numeric Customer’s date of birth, in the format YYYYMMDD Optional
address1 50/String Customer’s address line 1 Mandatory
city 50/String Customer’s city Mandatory
state 2/String Customer’s state (two-letter state code). Please see Reference for a list of valid state codes Conditional
zip_code 10/String Customer’s ZIP code Mandatory
country 2/String Customer’s country(two-letter country code). Please see Reference for a list of valid country codes Mandatory
phone 15/String Customer’s full international phone number, including country code Mandatory
cell_phone 15/String Customer’s full international cell phone number, including country code Optional
email 50/String Customer’s email address Mandatory
currency 3/String Currency the transaction is charged in (three-letter currency code). Sample values are: USD for US Dollar EUR for European Euro Optional
ipaddress 45/String Customer’s IP address, included for fraud screening purposes Mandatory
site_url 128/String URL the original sale is made from Optional
control 40/String Checksum generated by SHA-1. See Request authorization through control parameter for more details Mandatory
redirect_url 128/String URL the cardholder will be redirected to upon completion of the transaction. Please note that the cardholder will be redirected in any case, no matter whether the transaction is approved or declined. You should not use this parameter to retrieve results from Payneteasy gateway, because all parameters go through client’s browser and can be lost during transmission. To deliver the correct payment result to your backend use server_callback_url instead Mandatory if both redirect_success_url and redirect_fail_url are missing
redirect_success_url 1024/String URL the cardholder will be redirected to upon completion of the transaction. Please note that the cardholder will be redirected only in case if the transaction is approved. You should not use this parameter to retrieve results from Payneteasy gateway, because all parameters go through client’s browser and can be lost during transmission. To deliver the correct payment result to your backend use server_callback_url instead Mandatory if redirect_url parameter is missing
redirect_fail_url 1024/String URL the cardholder will be redirected to upon completion of the transaction. Please note that the cardholder will be redirected only in case if the transaction is declined or filtered. You should not use this parameter to retrieve results from Payneteasy gateway, because all parameters go through client’s browser and can be lost during transmission. To deliver the correct payment result to your backend use server_callback_url instead Mandatory if redirect_url parameter is missing
server_callback_url 128/String URL the transaction result will be sent to. Merchant may use this URL for custom processing of the transaction completion, e.g. to collect sales data in Merchant’s database. See more details at Merchant Callbacks Optional
preferred_language 2/String Customer’s two-letter language code for multi-language payment forms Optional
merchant_form_data 128/String Parameters sent in merchant_form_data API parameter are parsed into macros with the same name, the parameter is url-encoded, example: testparam%3Dtest1%26mynewparam%3Dtest2 and is parsed into $MFD_testparam = test1 and $MFD_mynewparam = test2 macros in the form. Parameter name characters[a-zA-Z0-9], parameter value characters[a-zA-Z0-9], control characters [=&], 2MB max size Optional
* leading and trailing whitespace in input parameters will be omitted

Account verification form Response

All parameters in response are encoded in application/x-www-form-urlencoded MIME format

Response parameter name Description
type The type of response. May be async-form-response, validation-error, error. If type equals validation-error or error, error-message and error-code parameters contain error details
paynet-order-id Order id assigned to the order by Payneteasy
merchant-order-id Merchant order id
serial-number Unique number assigned by Payneteasy server to particular request from the Merchant
error-message If status is declined or error this parameter contains the reason for decline or error details
error-code The error code in case of declined or error status
redirect-url The URL to the page where the Merchant should redirect the client’s browser. Merchant should send HTTP 302 redirect, see Account verification form diagram

Account verification form final redirect

Upon completion of Account verification form process by the Customer he/she is automatically redirected to redirect_url. The redirection is performed as an HTTPS POST request with the parameters specified in the following table.

Redirect parameter name Description
status See Status List for details
orderid Order id assigned to the order by Payneteasy
merchant_order Merchant order id
client_orderid Merchant order id
error_message If status is declined or error this parameter contains the reason for decline or error details
control Checksum used to ensure that it is Payneteasy (and not a fraudster) that initiates the request. This is SHA-1 checksum of the concatenation status + orderid + client_orderid + merchant-control
descriptor Gate descriptor
processor-tx-id Acquirer transaction identifier
amount Actual transaction amount
bin Bank BIN of customer credit card number
type The type of response
card-type Type of customer credit card
phone Customer phone
last-four-digits Last four digits of customer credit card number
card-holder-name Cardholder name
error_code Error Code

Account verification form template sample

<html>
<head>
<script type="text/javascript">
  function isCCValid(r){var n=r.length;if(n>19||13>n)return!1;
    for(i=0,s=0,m=1,l=n;i<l;i++)d=parseInt(r.substring(l-i-1,l-i),10)*m,s+=d>=10?d%10+1:d,1==m?m++:m--;
    return s%10==0?!0:!1}
</script>
</head>
<body>
<h3>Order #$!MERCHANT_ORDER_ID - $!ORDERDESCRIPTION</h3>

<form action="${ACTION}" method="post">
  <div>Card number: <input id="cardnumber" name="${CARDNO}" type="text" maxlength="19" autocomplete="off"/></div>
  $!{INTERNAL_SECTION}
  #if($!card_error)
  <div style="color: red;">$!card_error</div>
  #end
  <input name="submit" onclick="return isCCValid(document.getElementById('cardnumber').value);" type="submit" value="Verification"/>
</form>
</body>
</html>

Account verification form macros

Field Name Macro Field Value Macro Description
${CARDNO} ${CARDNOVALUE} Customer’s credit card number
${MERCHANT} n/a End point display name
${SKIN_VERSION} n/a CSS skin version
${ORDERDESCRIPTION} n/a Order description
${CUSTOMER_FIRST_NAME} n/a Customer first name sent by merchant via input parameters
${CUSTOMER_LAST_NAME} n/a Customer last name sent by merchant via input parameters
${CUSTOMER_EMAIL} n/a Customer E-mail address sent by merchant via input parameters
${PAYNET_ORDER_ID} n/a Payneteasy order id
${MERCHANT_ORDER_ID} n/a Merchant order id
${refresh_interval} n/a Refresh interval recommended by system
${uuid} n/a Internal
${INTERNAL_SECTION} n/a Internal for iFrame integration
${CUSTOMER_IP_COUNTRY_ISO_CODE} n/a Customer country defined by IP Address
${PREFERRED_LANGUAGE} n/a Customer language sent by merchant via input parameters
${BROWSER_LANGUAGE} n/a Customer language defined by browser settings
${CUSTOMER_LANGUAGE} n/a Customer language sent by merchant via input parameters or defined by browser settings if first is not set
${$MERCHANT_FORM_DATA} n/a Parameters sent in merchant_form_data API parameter are parsed into macros with the same name, the parameter is url-encoded, example: testparam%3Dtest1%26mynewparam%3Dtest2 and is parsed into $MFD_testparam = test1 and $MFD_mynewparam = test2 macros in the form. Parameter name characters[a-zA-Z0-9], parameter value characters[a-zA-Z0-9], control characters [=&], 2MB max size

Wait page template sample

<html>
<head>
<script type="text/javascript">
  function fc(t) {
    document.getElementById("seconds-remaining").innerHTML = t;
    (t > 0) ? setTimeout(function(){fc(--t);}, 1000) : document.checkform.submit();}
</script>
</head>
<body onload="fc($!refresh_interval)">
<h3>Order #$!MERCHANT_ORDER_ID - $!ORDERDESCRIPTION</h3>
Please wait, your payment is being processed, remaining <span id="seconds-remaining">&nbsp;</span> seconds.
<form name="checkform" method="post">
  <input type="hidden" name="tmp" value="$!uuid"/>
      $!{INTERNAL_SECTION}
  <input type="submit" value="Check" />
</form>
</body>
</html>

Wait page macros

Field Name Macro Field Value Macro Description
${MERCHANT} n/a End point display name
${SKIN_VERSION} n/a CSS skin version
${ORDERDESCRIPTION} n/a Order description
${PAYNET_ORDER_ID} n/a Payneteasy order id
${MERCHANT_ORDER_ID} n/a Merchant order id
${refresh_interval} n/a Refresh interval recommended by system
${uuid} n/a Internal
${INTERNAL_SECTION} n/a Internal for iFrame integration
${CUSTOMER_IP_COUNTRY_ISO_CODE} n/a Customer country defined by IP Address
${PREFERRED_LANGUAGE} n/a Customer language send by merchant via input parameters
${BROWSER_LANGUAGE} n/a Customer language defined by browser settings
${CUSTOMER_LANGUAGE} n/a Customer language send by merchant via input parameters or defined by browser settings if first is not set

Finish page macros

Field Name Macro Field Value Macro Description
${STATUS} n/a Order status
${PAYNET_ORDER_ID} n/a System order id
${MERCHANT_ORDER_ID} n/a Merchant order id
${ERROR_MESSAGE} n/a Contains the reason for decline or error details
${SKIN_VERSION} n/a CSS skin version
${CUSTOMER_IP_COUNTRY_ISO_CODE} n/a Customer country defined by IP Address
${PREFERRED_LANGUAGE} n/a Customer language send by merchant via input parameters
${BROWSER_LANGUAGE} n/a Customer language defined by browser settings
${CUSTOMER_LANGUAGE} n/a Customer language send by merchant via input parameters or defined by browser settings if first is not set

Account verification form Postman Collection

Account verification form Request Debug

endpointid input your ENDPOINTID
client_orderid make it or use your internal invoice ID
order_desc
first_name
last_name
ssn
birthday
address1
city
state
zip_code
country
phone
cell_phone
email
ipaddress
site_url
currency
purpose
merchant_control input your Control Key
redirect_url
redirect_success_url
redirect_fail_url
server_callback_url
merchant_data
merchant_form_data

String to sign
Signature

Account verification request authorization through control parameter

The checksum is used to ensure that it is a particular Merchant (and not a fraudster) that initiates the transaction. This SHA-1 checksum, the parameter control, is created by concatenation of the parameters values in the following order:

  • ENDPOINTID
  • client_orderid
  • email
  • merchant_control

A complete string example may look as follows:

1902B4FF5john.smith@gmail.comB17F59B4-A7DC-41B4-8FF9-37D986B43D20

Encrypt the string using SHA-1 algorithm. The resultant string yields the control parameter (see Account verification Request Parameters) which is required for request authorization. For the above-mentioned example the control will take the following value:

45dec98f9d69000a9f41bdb4ace47a7755fd47cd

Order status

Merchant must use Order status API call to get the customer’s order transaction status. After any type of transaction is sent to Payneteasy server and order id is returned, Merchant should poll for transaction status. When transaction is processed on Payneteasy server side it returns it’s status back to Merchant and at this moment the Merchant is ready to show the customer transaction result, whether it’s approved or declined.

Status API URL

For integration purposes use staging environment sandbox.payneteasy.eu instead of production gate.payneteasy.eu. Status API calls are initiated through HTTPS POST request by using URL in the following format:

Order status call parameters

Status call parameters Description Necessity
login Merchant login name Mandatory
client_orderid Merchant order identifier of the transaction for which the status is requested Mandatory
orderid Order id assigned to the order by Payneteasy Conditional
by-request-sn Serial number assigned to the specific request by Payneteasy. If this field exist in status request, status response return for this specific request. Include this parameter to get the status response with the particular transaction stage (can be used in specific cases). To get the latest transaction status, don’t include this parameter in status request Optional
control Checksum used to ensure that it is Payneteasy (and not a fraudster) that initiates the callback for a particular Merchant. This is SHA-1 checksum of the concatenation login + client-order-id + paynet-order-id + merchant-control. See Order status API call authorization through control parameter for more details about generating control checksum Mandatory
In most common cases, the best option is to include both client_orderid and orderid parameters to status request. Order status can be requested with only client_orderid if it’s unique to merchant and orderid is not received. If orderid is not received in response, but this response contains an error, see the received error message to get the information why transaction was not created in the system.

Order Status Response

All parameters in response are encoded in application/x-www-form-urlencoded MIME format

Status Response Parameters Description
type The type of response. May be status-response
status See Status List for details
paynet-order-id Order id assigned to the order by Payneteasy
merchant-order-id Merchant order id
phone Customer phone
serial-number Unique number assigned by Payneteasy server to particular request from the Merchant
last-four-digits Last four digits of customer credit card number
bin Bank BIN of customer credit card number
card-type Type of customer credit card (VISA, MASTERCARD, etc)
gate-partial-reversal Processing gate support partial reversal (enabled or disabled)
gate-partial-capture Processing gate support partial capture (enabled or disabled)
transaction-type Transaction type (sale, reversal, capture, preauth)
processor-rrn Bank Receiver Registration Number
processor-tx-id Acquirer transaction identifier
receipt-id Electronical link to receipt https://gate.payneteasy.eu/paynet/view-receipt/ENDPOINTID/receipt-id/
name Cardholder name
cardholder-name Cardholder name
card-exp-month Card expiration month
card-exp-year Card expiration year
card-hash-id Unique card identifier to use for loyalty programs or fraud checks
card-country-alpha-three-code Three letter country code of source card issuer. See Country Codes for details
email Customer e-mail
first-name Customer’s first name
last-name Customer’s last name
country * Customer’s country (two-letter country code). Please see Country Codes for a list of valid country codes.
state * Customer’s state . Please see Country Codes for a list of valid state codes. Mandatory for USA, Canada and Australia.
city * Customer’s city
zip_code * Customer’s ZIP code
address1 * Customer’s address line 1
purpose Destination to where the payment goes. It is useful for the merchants who let their clients to transfer money from a credit card to some type of client’s account, e.g. game or mobile phone account. Sample values are: +7123456789; gamer0001@ereality.com etc. This value will be used by fraud monitoring system
bank-name Bank name by customer card BIN
terminal-id Acquirer terminal identifier to show in receipt
paynet-processing-date Acquirer transaction processing date
approval-code Bank approval code
order-stage The current stage of the transaction processing. See Order Stage for details
loyalty-balance The current bonuses balance of the loyalty program for current operation. if available
loyalty-message The message from the loyalty program. if available
loyalty-bonus The bonus value of the loyalty program for current operation. if available
loyalty-program The name of the loyalty program for current operation. if available
descriptor Bank identifier of the payment recipient
original-gate-descriptor Descriptor, which is set on gate level in the system
error-message If status in declined, error, filtered this parameter contains the reason for decline
error-code The error code is case status in declined, error, filtered
by-request-sn Serial number assigned to the specific request by Payneteasy. If this field exist in status request, status response return for this specific request
card-ref-id Card referense ID to used in subsequent recurrent payments
verified-3d-status See 3-D Secure Status List for details
eci Electronic Commerce Indicator (Visa)
ips-src-payment-product-code Code for card set by multinational financial service. (Visa/Mastercard)
ips-src-payment-product-name Decrypted code for card set by multinational financial service. (Visa/Mastercard)
ips-src-payment-type-code Type of card code set by multinational financial service. (Visa/Mastercard)
ips-src-payment-type-name Decrypted code for type of card set by multinational financial service. (Visa/Mastercard)
initial-amount Amount, set in initiating transaction, without any fees or commissions. This value can’t change during the transaction flow
transaction-date Date of final status assignment for transaction.

Note

* - these parameters are not defined by default. Please contact tech support to include these fields in callback.

Order Status Response Example

type=status-response
&serial-number=00000000-0000-0000-0000-00000456fa77
&merchant-order-id=avaw23wefd
&processor-tx-id=PNTEST-3622351
&paynet-order-id=3622351
&status=approved
&amount=0.00
&currency=GBP
&descriptor=Minatory
&original-gate-descriptor=test 12345678 3Ds Bank
&transaction-type=account_verification
&receipt-id=54d9a433-5199-38d6-b531-61f383298121
&name=CARD+HOLDER
&cardholder-name=CARD+HOLDER
&card-exp-month=12
&card-exp-year=2099
&email=john.smith%40gmail.com
&last-name=Smith
&first-name=John
&processor-rrn=514174311400
&approval-code=473741
&order-stage=av_approved
&merchantdata=VIP+customer
&last-four-digits=6732
&bin=453897
&card-type=VISA
&phone=12063582043
&bank-name=MITSUBISHI+UFJ+NICOS+CO.+LTD.
&auth-response-code=00
&terminal-id=12345678
&paynet-processing-date=2015-05-21+16%3A08%3A30+MSK
&acquirer-processing-date=2015-05-21+16%3A08%3A30+MSK
&by-request-sn=00000000-0000-0000-0000-00000456fa76
&card-hash-id=212643
&card-ref-id=50705
&card-country-alpha-three-code=CYP
&verified-3d-status=AUTHENTICATED
&eci=02
&ips-src-payment-product-code=SAP
&ips-src-payment-product-name=SAP—Platinum Mastercard® Salary– Immediate Debit
&ips-src-payment-type-code=Debit
&ips-src-payment-type-name=MASTERCARD Debit
&initial-amount=0.00
&transaction-date=2023-01-10+12%3A46%3A28+MSK

Status request authorization through control parameter

The checksum is used to ensure that it is Merchant (and not a fraudster) that sends the request to Payneteasy. This SHA-1 checksum, the parameter control, is created by concatenating of the values of the parameters in the following order:

  • login
  • client_orderid
  • orderid
  • merchant_control

For example assume the following values are corresponds the parameters above:

Parameter Name Parameter Value
login cool_merchant
client_orderid 5624444333322221111110
orderid 9625
merchant_control r45a019070772d1c4c2b503bbdc0fa22

The complete string example may look as follows:

cool_merchant56244443333222211111109625r45a019070772d1c4c2b503bbdc0fa22

Encrypt the string using SHA-1 algorithm. The resultant string yields the control parameter which is required for authorizing the callback. For the example control above will take the following value:

c52cfb609f20a3677eb280cc4709278ea8f7024c

Order status Postman Collection

Order status Debug

endpointid input your ENDPOINTID
login
client_orderid input your Invoice Number
orderid
merchant_control input your Control Key
by-request-sn

String to sign
Signature