validate_acct_fraud_scoring_m Sample Call and Response
This example shows a call to validate_acct_fraud_scoring_m, which retrieves fraud scoring information for a given account and payment method. Depending on the fraud scoring threshold configuration defined for the payment gateway and collection group, the outcome can affect the merchant plug-in (MPI) status of a subsequent transaction. This example is based on the plsql_m_r73.yml definition file.
This example scores a proposed payment against an existing stored payment method and a single plan instance, along with a few fraud-relevant end-user details. It does not cover supplying raw card data directly on the call (alt_pay_method or cc_num), identifying the account, billing group, or plan instance by their client-defined alternatives, or the fraud_control_fields and fraud_field parameters.
Sample call
{
"rest_call": "validate_acct_fraud_scoring_m",
"output_format": "json",
"client_no": 66123,
"auth_key": "a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4",
"acct_no": 5017732,
"amount": 249.00,
"plan_instance_list": [
{
"plan_instance_no": 3312087
}
],
"payment_method_no": 771190,
"end_user_ip_address": "203.0.113.42",
"end_user_session_id": "SESS-20260724-9F3A21",
"bill_zip": "33602",
"bill_country": "US"
}
The rest_call and output_format fields are added by the REST layer and do not appear in the method's own argument list. acct_no and client_acct_id are alternatives; this example uses acct_no, the Aria-assigned account identifier. plan_instance_list is an array because an account can have more than one plan instance under evaluation at once, even though only one entry is shown here; each entry identifies a plan instance by plan_instance_no in preference to its alternative, client_plan_instance_id. billing_group_no, client_billing_group_id, alt_pay_method, payment_method_no, and client_payment_method_id form a group of alternatives; this example uses payment_method_no to score an already-stored payment method rather than supplying new card data on the call. end_user_ip_address, end_user_session_id, bill_zip, and bill_country are optional fields included here because they are commonly used fraud signals.
Sample response
{
"error_code": 0,
"error_msg": "OK",
"proc_status_code": "00",
"proc_status_text": "Approved",
"proc_fraud_scoring_info": {
"proc_fraud_score": "12",
"proc_fraud_score_result": "Low Risk"
},
"payment_method_no": 771190
}
error_code 0 and error_msg "OK" indicate that the fraud scoring check completed without error. proc_status_code and proc_status_text describe the processor's overall result, and proc_fraud_scoring_info reports the fraud score and its interpretation for this one authorization check; this field is treated as a single object rather than an array, since it represents one score result for the one payment method being evaluated, not a list of multiple entries. payment_method_no is echoed back to confirm which stored payment method was scored. This example leaves out error_details, collection_errors, and the remaining processor diagnostic fields (proc_cvv_response, proc_avs_response, proc_cavv_response, proc_auth_code, proc_merch_comments, proc_payer_auth_request, proc_redirect_issuer_url, proc_md, proc_initial_auth_txn_id, proc_fraud_filtering_info, proc_3dsecure_data, and processor_id), none of which are needed to illustrate the fraud scoring result.