record_alternative_payment_m Sample Call and Response
This example shows a payment collected outside Aria through an iDEAL transaction being recorded against an account, based on the record_alternative_payment_m method defined in plsql_m_r73.yml. All identifiers shown are clearly fake placeholder values and do not represent any real payment or account.
This example includes every required field and a representative set of optional fields for recording an alternative payment method transaction that was already authorized outside Aria. It does not cover recording a payment for every supported alternative payment method, the Apple Pay encrypted payload flow, or fraud-detection field submission.
Sample call
{
"rest_call": "record_alternative_payment_m",
"output_format": "json",
"client_no": 32409,
"auth_key": "a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6",
"acct_no": 5008842,
"reference_code": "ALT-PMT-REF-0092371",
"payment_amount": 89.50,
"processor_id": 34,
"pay_method_type": 32,
"statement_no": 3300118,
"billing_group_no": 220156,
"comments": "Alternative payment collected outside Aria via iDEAL and recorded for reconciliation.",
"client_receipt_id": "RCPT-2026-0092371",
"allow_recurring": "false",
"payment_auth_received": 1,
"proc_payment_method_id": "shopper-ref-778812"
}
The field acct_no identifies the account rather than its alternative, client_acct_id, since acct_no is the Aria-assigned numeric identifier. The field processor_id is set to 34, meaning Adyen manages this alternative payment method; other valid values include 16 (Global Collect, to be deprecated), 29 (WorldPay), 36 (Worldline, formerly Ingenico), 1 (Chase Paymentech), and 28 (Braintree). The field pay_method_type is set to 32, meaning iDEAL; other valid values include 30 (Boleto), 33 (WebMoney), 34 (Yandex), 35 (PaySafeCard), 36 (SOFORT), 38 (ApplePay - Indirect), 39 (PayPal Express Checkout - Indirect), 47 (Tokenized ApplePay), and 51 (Tokenized GooglePay). The field billing_group_no identifies the billing group rather than its alternative, client_billing_group_id. The field payment_auth_received is set to 1, indicating the client already received a successful authorization for this alternative payment method outside Aria; the other valid value is 0 (not received successfully, the default). The field allow_recurring is set to the string value "false", meaning this payment method is not designated for subsequent recurring payments; the other valid value is "true". The fields rest_call and output_format are envelope fields added by the REST layer and are not part of the method's own documented arguments.
This example leaves out external_id and external_destination_id, which are marked nonpublic and used only for internal purposes; external_payment_payload, which applies only to the Apple Pay encrypted payload flow rather than a already-authorized iDEAL payment; primary_payment_method_ind, which would designate this alternative payment method as the primary payment method for the billing group; and fraud_field, an enumerated list of fraud-detection data points not needed for this reconciliation scenario.
Sample response
{
"error_code": 0,
"error_msg": "OK",
"auth_no": 660123489,
"proc_response_fields": [
{
"proc_field_name": "payment_redirect_issuer_url",
"proc_field_value": "https://processor.example.com/ideal/redirect/9a8b7c6d"
}
]
}
The error_code value of 0 and the error_msg value of "OK" indicate that the payment was recorded without error, and auth_no is the unique number Aria assigned to this authorization. The proc_response_fields array shows one representative entry, a payment_redirect_issuer_url value used to complete an iDEAL transaction; a response could contain additional processor-specific fields depending on the alternative payment method used. This example leaves out the error_details field entirely, since that field is marked nonpublic in the yml and is not populated in responses to client callers.