X-Payments:Accept potentially fraudulent transaction request

X-Payments API

1. API versions supported
2. Samples
3. API requests
   • Request/Response encryption
   • Encryption and communication
   • cURL as a means of sending requests
   • Data types
4. API Requests from the store to X-Payments
   1. Admin area/X-Payments configuration
      • Test connection request
      • Payment configurations list request
   2. Payment creation (Regular payment and tokenization)
      • Payment initialisation request
      • Charge again transaction request (Tokenization)
   3. Payment information
      • Payment information request
      • Detailed payment and transaction information request
   4. Actions on payments (secondary actions)
      • Capture authorized transaction request
      • Void authorized transaction request
      • Refund captured transaction request
      • Accept potentially fraudulent transaction request
      • Decline potentially fraudulent transaction request
5. Callback requests (web-hooks) from X-Payments to the store
   • Callback request with service payment information
   • Check cart callback request
6. Browser-related
   • Redirecting a customer to the cardholder data entering page
   • Communication between X-Payments iframe and the store
7. Appendix A. Status codes.
   • Payment status codes
   • Operation status codes
8. See also

In some cases, a transaction is considered potentially fraudulent, and the final decision as to whether it should be accepted or not has to be taken by the merchant. Or, in some cases, the information about the final result is sent to the merchant later by the anti-fraud checking service.

Such a state of the transaction is indicated by the isFraudStatus flag in the Payment information request, Detailed payment information request and the callback request received from X-Payments. As of API 1.7, the detailed information on fraud check is sent in the fraudCheckData container.

Currently, there are four cases that can put a transaction in the "potentially fraudulent" state:

• Kount Antifraud screening service;
• NoFraud screening;
• Internal fraud screening by the gateway (PayPal, PayFlow PRO, etc);
• Internal fraud screening by X-Payments.

Note: Please contact your antifraud service provider for recommendations on how to handle transactions marked as potentially fraudulent. Deciding which transactions to accept and which to decline is a serious matter, and you must fully understand what you are doing before you accept anything.

Request specification

Field	Required	Type	Description
target	Y	string, 128	Must equal payment
action	Y	string, 128	Must equal accept
txnId	Y	string, 32	Unique payment ID
api_version	Y	string	Must equal one of the following: 1.2, 1.3, 1.4, 1.5 etc.

Request example

<txnId>e7f398cee98ec062abac0d2c937da181</txnId>
<target>payment</target>
<action>accept</action>

Response specification

Field	Type	Description
status	integer, 1	Operation status code
message	string, 65536	Gateway transaction message
payment	container	(Only API 1.9) Container with Payment information

Response example

<data>
<status>1</status>
<message>Success</message>
<error></error>
<error_message></error_message>
</data>