Difference between revisions of "X-Payments:Decline potentially fraudulent transaction request"

From X-Payments Help
Jump to: navigation, search
m
m
Line 6: Line 6:
 
Currently, there are four cases that can put a transaction in the "potentially fraudulent" state:
 
Currently, there are four cases that can put a transaction in the "potentially fraudulent" state:
  
- [[X-Payments:KOUNT_Antifraud_screening|Kount Antifraud screening service]];
+
:* [[X-Payments:KOUNT_Antifraud_screening|Kount Antifraud screening service]];
- NoFraud screening;
+
:* NoFraud screening;
- Internal fraud screening by the gateway (PayPal, PayFlow PRO, etc);
+
:* Internal fraud screening by the gateway (PayPal, PayFlow PRO, etc);
- Internal fraud screening by X-Payments.
+
:* 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.}}
 
{{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.}}

Revision as of 14:38, 21 November 2016

X-Payments API
  1. API versions supported
  2. Samples
  3. API requests
  4. API Requests from the store to X-Payments
    1. Admin area/X-Payments configuration
    2. Payment creation (Regular payment and tokenization)
    3. Payment information
    4. Actions on payments (secondary actions)
  5. Callback requests (web-hooks) from X-Payments to the store
  6. Browser-related
  7. Appendix A. 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:

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 decline
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>decline</action>

Response specification

Field Type Description
status integer, 1 Operation status code
message string, 65536 Gateway transaction message

Response example

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