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

From X-Payments Help
Jump to: navigation, search
m
m (Response specification)
 
(2 intermediate revisions by the same user not shown)
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.}}
Line 64: Line 64:
 
| colspan="1" | string, 65536
 
| colspan="1" | string, 65536
 
| colspan="1" | Gateway transaction message
 
| colspan="1" | Gateway transaction message
 +
|-
 +
| colspan="1" | payment
 +
| colspan="1" | container
 +
| colspan="1" | (Only API 1.9) Container with [[X-Payments:Payment_information_request#PaymentInfoSpecification | Payment information]]
 
|}
 
|}
  

Latest revision as of 16:04, 24 April 2018

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 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>