Case management

You may want to manually review a transaction before it is captured for an extra layer of fraud protection. Manual review is commonly used for:

• High Transaction Values: If you have very high Average Transaction Values (ATVs), you may find that the monetary loss of even a single chargeback justifies the operational costs of manual review.

• Expanding into High-Risk Markets: If you expand to a high-risk region, it is a good idea to manually review transactions to minimize fraudulent payments.

Configure case management

Set user roles to allow case management

To use manual case management in the Customer Area, your user must have the appropriate role added. To add the Merchant Manual Review or Risk Admin to an existing user:

1. In the Account section, select Users.
2. Select the user to be modified.
3. In the Roles list, turn on the Merchant Manual Review or Risk Admin role.

Set a trigger for manual review

A transaction can be set aside for manual review when:

1. The transaction reaches a minimum score that you set. Payments that reach a risk score of 100 or more are refused. You can also set minimum score for manual review at the merchant-level account on a risk profile. If this limit is exceeded, the transaction is sent for manual review.
2. The transaction triggers a risk rule that has Send to case management turned on. When this option is turned on, the transaction is sent for manual review whenever that rule was triggered.

For example, if the Transaction Amount Check is set to flag transactions over $1000, and Send to case management is turned on, the transaction will be sent to case management.

Implementing manual review

Following are the steps to help implement manual review:

1. Use the fraudResultType field in the payment response for AMBER status. AMBER status means the payment was authorised but not auto-captured. This fraudResultType is included in the additionalData of the API response of your authorization request. Our support team can also setting/feature to have this included in your asynchronous notification.
2. In your system, place the order in a different status to ensure you don't ship the product. It is recommended that you update this in your ERP.
3. A user with access to the Case Management UI can now perform the manual review in include  and decide whether to accept or reject this payment.
4. Define the modification requests you want the manual actions for and the notifications you want Adyen to send to your servers for these decision points:
   • Accept: Capture or no action
   • Reject: Cancel_or_Refund or no action
   • Expiry: Define what modifications you want no action for at the end of 7 days: Cancel_or_Refund or Capture.
5. Use the asynchronous notifications with event code MANUAL_REVIEW_ACCEPT or MANUAL_REVIEW_REJECT to update the status of the order in your system.

Capture or cancel modifications can be handled by Adyen or you can also choose to handle it yourself. Contact support to know more.

Receive notifications and take action

At the time of manual review, the transaction has already been authorised by the issuing bank. From there, the behavior of the case management system then determines if the transaction is to be captured, refunded, or canceled. 

You can implement additional logic based on whether or not a transaction is in the manual review. For example, they may delay shipment until the manual review has occurred. The payment request response includes this crucial information in the fraudResultType field. Note that a manual review is indicated with the AMBER status.

    <?xml version="1.0" encoding="UTF-8"?>
    <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema- instance">
       <soap:Body>
          <ns1:authoriseResponse xmlns:ns1="http://payment.services.adyen.com">
             <ns1:paymentResult>
                <additionalData xmlns="http://payment.services.adyen.com">
                   <entry>
                      <key xsi:type="xsd:string">fraudResultType</key>
                      <value xsi:type="xsd:string">AMBER</value>
                   </entry>
                   <additionalData />
                   <authCode>85883</authCode>
                   <dccAmount xsi:nil="true" />
                   <dccSignature xsi:nil="true" />
                   <fraudResult>
                      <accountScore>0</accountScore>
                      <results>
                         <FraudCheckResult>
                            <accountScore>0</accountScore>
                            <checkId>7</checkId>
                            <name>ShopperIpUsage</name>
                         </FraudCheckResult>
                         <FraudCheckResult>
                            <accountScore>0</accountScore>
                            <checkId>8</checkId>
                            <name>ShopperEmailUsage</name>
                         </FraudCheckResult>
                      </results>
                   </fraudResult>
                </additionalData>
                <issuerUrl xmlns="http://payment.services.adyen.com" xsi:nil="true" />
                <md xmlns="http://payment.services.adyen.com" xsi:nil="true" />
                <paRequest xmlns="http://payment.services.adyen.com" xsi:nil="true" />
                <pspReference xmlns="http://payment.services.adyen.com">9914169226820173</pspReference>
                <refusalReason xmlns="http://payment.services.adyen.com" xsi:nil="true" />
                <resultCode xmlns="http://payment.services.adyen.com">Authorised</resultCode>
             </ns1:paymentResult>
          </ns1:authoriseResponse>
       </soap:Body>
    </soap:Envelope>

You can receive notifications when a payment has been accepted, rejected or expired in the Case Management system. It is important to have additional logic to process such rejections. For example, they may send a notification to their warehouse to not ship the goods in question. In the case of digital goods, they may choose to have the user's account disabled upon notification of a manual review rejection. 

• Manual Review has been accepted:

  • ACCEPT_NOTIFICATION. Adyen sends an ACCEPT notification to the merchant when an agent has selected to approve the manual review.
  • None: No notification is sent.
• Manual Review has been rejected:

• • REJECT_NOTIFICATION. Adyen sends a REJECT notification to the Merchant when an agent has selected to reject a transaction in the manual review.

  • None: No notification is sent.

• Manual Review has expired:

  • ACCEPT_NOTIFICATION. Adyen sends an ACCEPT notification to the merchant when the review has expired and the account was configured to accept upon expiration. 

  • REJECT_NOTIFICATION. Adyen sends a REJECT notification to the merchant when the review has expired and the account was configured to reject upon expiration. 

  • None: No notification is sent. 

An example SOAP notification indicating the result of the manual Review. Note the 'MANUAL_REVIEW_ACCEPT' eventCode.

    <?xml version="1.0" encoding="UTF-8"?>
    <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema- instance">
       <soap:Body>
          <ns1:sendNotification xmlns:ns1="http://notification.services.adyen.com">
             <ns1:notification>
                <live xmlns="http://notification.services.adyen.com">false</live>
                <notificationItems xmlns="http://notification.services.adyen.com">
                   <notificationRequestItem>
                      <additionalData xsi:nil="true" />
                      <amount>
                         <currency xmlns="http://common.services.adyen.com">EUR</currency>
                         <value xmlns="http://common.services.adyen.com">1700</value>
                      </amount>
                      <eventCode>MANUAL_REVIEW_ACCEPT</eventCode>
                      <eventDate>2014-10-22T16:33:27.787+02:00</eventDate>
                      <merchantAccountCode>TestMerchant</merchantAccountCode>
                      <merchantReference>TMRef1234</merchantReference>
                      <operations xsi:nil="true" />
                      <originalReference>9914135462408734</originalReference>
                      <paymentMethod>visa</paymentMethod>
                      <pspReference>9914135462569048</pspReference>
                      <reason>accept</reason>
                      <success>true</success>
                   </notificationRequestItem>
                </notificationItems>
             </ns1:notification>
          </ns1:sendNotification>
       </soap:Body>
    </soap:Envelope>

Modifications

Merchants can decide what action takes place to the payment after it has expired or has been accepted/rejected by the manual reviewer. Note that these configurations are implemented by Adyen support based on the merchant's needed behavior.

• Manual Review has been accepted:

  • CAPTURE: The payment is captured.

  • None: No modification is performed to the payment. 

• Manual Review has been rejected:

  • CANCEL_OR_REFUND: The payment is canceled or refunded (whichever is appropriate for the payment method).

  • None: No modification is performed to the payment.

•  Manual Review has expired:

  • CAPTURE: The payment is captured.

  • CANCEL_OR_REFUND: The payment is canceled or refunded (whichever is appropriate for the payment method).

  • None: No notification is performed to the payment.

Review Payments

The manual review queue allows you to review payments, assign the cases to users, and accept or reject the payment.

Access the manual review queue

The manual review queue is available through the Customer Area:

1. Log in to your Customer Area.
2. Go to Risk > Case Management .
   The page displays a list of payments under review
3. Assigned or unassigned cases that are not closed (accepted or rejected) are listed under Open cases

Assign reviews

Assign reviews to specific reviewers to avoid duplicating or overlap of effort:

1. Select the check box to the left of the PSP references of cases you want to review.

   Actions are disabled until you select a case.

2. Click Assign to.
3. Search for a merchant-level account in the drop-down menu. Your own account will always be listed first.
4. Select the account you want to assign to. 
5. Click Confirm.
   The page will refresh and the name of the assignee will be listed under the Assigned to column. If a case is assigned to you, it will be listed under My cases.

Accept or Reject payments

Manual review involves either accepting or rejecting payments:

1. Select the check box to the left of the PSP references of case(s) you want to accept or reject.

   Accept or reject several payments at once by selecting multiple check boxes.

2. Click Accept to accept the payment(s). 
3. Click Reject to reject the payment(s). 

Change the decision on past reviews

After a decision is made on a case, the payment will disappear from the Open cases list. You can still find these cases in the Closed cases list.

To change the decision on a past review:

1. Log in to your Customer Area.
2. Go to Risk > Case management.
3. Select Closed cases.
4. Select the case from the list.
5. Under Case Details, select the Manual Status drop down.
   
6. Select either Fraud or Genuine.

If the transaction was canceled due to a rejected review, this is a permanent decision that cannot be reversed.  However, it is still important to document the proper status for a manual review as, in future, reviewers can reference this status and decide to accept or reject payments.