This feature sends flags distinguishing cardholder initiated transactions (CIT) and merchant initiated transactions (MIT) within the <recurring_processing_model_ind> parameter of the following API calls:
The input values for the <recurring_processing_model_ind> are the following:
- Cardholder-Initiated Transaction—Credentials on File: a credit card transaction initiated by the cardholder for a new order or a plan upgrade that uses a credit card that is currently stored in Aria. (Default)
- Cardholder-Initiated Transaction—a credit card transaction initiated by the cardholder for a new account or creating an order that uses an alternate credit card that is not currently stored in Aria.
- Merchant-Initiated Transaction—Standing Instruction – Recurring: a credit card transaction initiated by Aria’s clients for a recurring charge that uses a credit card that is currently stored in Aria.
- Merchant-Initiated Transaction—Unscheduled Credentials on File: a credit card transaction initiated by Aria’s clients for a non-recurring charge (one-time order or plan upgrade) that uses a credit card that is currently stored in Aria.
The output field of this call is <proc_initial_auth_txn_id>.
Fraud Scoring and Level 2/Level 3 Payments Now Supported
The Stripe payment processor integration has been enhanced to support fraud scoring and Level 2/Level 3 payments. Since Stripe fraud scoring returns both “review” and “failure” statuses, Aria has introduced the following fraud scoring settings on the collection group and payment gateway screens: Send Fraud Scoring Request, Change Status on Fraud Scoring Failure, Status on Fraud Scoring Failure, Change Status on Fraud Scoring Review, and Status on Fraud Scoring Review. For Level 2/Level 3 payments, these data are sent for payment actions regardless of Level 2/Level 3 eligibility; Stripe will pass this information on to the card networks for eligible transactions.
Stripe also supports fraud scoring for 3DS-enabled merchants, which allows you to obtain an account holder's fraud score or fraud score assessment. This can be implemented through a Direct Post configuration or the validate_acct_fraud_scoring_m API.
The Stripe payment gateway now supports the Account Updater for Visa® and Mastercard® card brands. When enabled, the account updater automatically updates your account holders' card information if available. The new field Webhook Secret was introduced at the payment gateway and collection group level (Configuration > Payments > [Payment Gateways/Collection Groups] > Merchant Account Details); this provides an extra layer of security for data verification and message authentication for webhook notifications received from Stripe.
This feature supports Stripe event notification for the below behind-the-scenes events in Aria and updates client billing records:
The Webhook Secret appears as shown:
Clients must configure their merchant account to allow webhook notifications by setting the end point URL in the Stripe dashboard. The endpoint URL has the following values:
|Client Number (Required)||The Aria client number|
|Group Number (Optional)||
If the client would like notifications for a specific collection group, they can specify the collection group number in the URL.
Note: If a collection group is not specified, the payment gateway settings will be used as a default.
Tokenized Credit Card Support for Smart Payments
The Stripe payment processor is now integrated as part of Aria’s smart payments with this release for the Tokenized Credit Card payment method (pay method 13). The following transactions are supported with this integration: capture, payment, and create/query token.
The following card types are supported:
- American Express
- Diners Club International
- Japan Credit Bureau (JCB)
For tokens created in Aria, the token/agreement_id is stored in the format “payment_method_id:customer_id” in Aria. For tokens created outside of Aria, you should create both the payment method ID and customer ID and combine them (payment_method_id:customer_id) in the “bill_agreement_id” field. If either the ID is missing or the token is not in a valid format when attempting to process a payment, Aria will generate an error saying "Invalid token. The valid token format is payment_method_id:customer_id."
Additional Stripe Smart Payments Features
Aria introduces the new Smart Payments adapter for the Stripe payment gateway. The following features are included in Phase 1:
- Authorization and Capture
- Cancel/Reverse Authorizations
- Fraud Scoring
- Soft Descriptor
Tokenization/Authorization and Capture/Refunds
This ticket includes the integration of the Authorization and Capture into the Stripe Payment Processor.
- American Express
- Japan Credit Bureau (JCB)
Since Stripe allows only the token based integration, Aria uses the “payment_method_id” and “customer_id” for making initial/recurring payments; card information is not used for payments. For this reason, we have implemented Tokenized credit card support for Stripe integration. For the token created by Aria, we are creating and storing the token/agreement_id in a format of "payment_method_id:customer_id" in Aria.
Refunds are also supported for the listed card types. At this time, Stripe only supports tokenized credit card refunds.
Stripe supports cancelling/reversing transactions via the UI or APIs using the <auth_no> of the authorized transaction. This applies to any amount greater than 0.
Since Stripe fraud scoring returns both “review” and “failure” statuses, the following existing settings in the Stripe UI are utilized for fraud scoring (for the payment gateway and collection group levels):
- Send Fraud Scoring Request
- Change Status on Fraud Scoring Failure
- Status of Fraud Scoring Failure
- Change Status on Fraud Scoring Review
- Status on Fraud Scoring Review
Once the “Send Fraud Scoring Request” option is enabled, we will be returning the fraud score and result are returned in <proc_fraud_score> and <proc_fraud_score_result> output of the validate_acct_fraud_scoring(_m) APIs. The possible values in <proc_fraud_score_result> are:
- Authorized: Successful (normal or no fraud risk transaction)
- Manual_Review: Review (elevated risk transaction - increased chance of being fraudulent)
- Blocked: Failure (transaction getting blocked or failing due to high risk, fraudulent transaction)
Stripe Smart Payments also includes soft descriptor support, which can be used by merchants to provide more detailed transaction information. Soft descriptor support is provided at various levels within Aria. The priority is as follows:
- Collection Group
- Payment Gateway
When a transaction occurs using a credit/debit card, the description is displayed under the statement_descriptor_suffix in the Payment Intent of the specific transaction. If the received soft descriptor value is more than 22 characters long, it is truncated to 22 characters before it is sent to the payment processor.
Note: Stripe statement descriptor needs to be 5-22 characters including the * symbol and the space, and cannot contain the character <, >, \, ', ", or *.
Stripe 3DS versions 1.0 and 2.0 support is now added for Stripe using Aria APIs and Direct Post. To use 3DS, the appropriate URL must be included in the Payer Authentication Settings field in the Payment Gateway and/or Collection Groups UI screens (Configuration > Payments > Payment Gateways/Collection Groups). Otherwise, the transaction will not complete, generating a validation error.
For the 3DS Termination URL, you must specify the Merchant website URL in the Payment Gateway/Collection Group UI Screens (which will be invoked when the shopper challenge is complete). For direct posts, the value should be
'https://secure.<environment>.ariasystems.net/api/auth_3ds2_notification_receiver.php,” where the environment will be different for QU, stage, and production.
Stripe 3DS is a three-step process as shown below:
Step 1: Execute the authorize_electronic_payment_m or update_payment_method_m API with credit card details, billing address details, and <attemt_3d_secure> as 'true' to perform client authentication, and then the API will return the <proc_payment_id> (as the outer level output field) and 'redirect_issuer_url' (value in the proc_3dsecure_data/proc_3dsecure_auth_data array) in the response.
- If the <attempt_3d_secure> input is passed as 'false', then the 3DS flow will be skipped and regular authorization will be invoked here. So, the below steps are not needed.
- Also, if the supplied credit card is not enrolled with 3DS and if Aria passes the <attempt_3d_secure> input as 'true', then the 3DS flow will be skipped and regular authorization will be invoked; Steps 2 and 3 will be skipped.
Step 2: Use the 'redirect_issuer_url' directly in the browser and execute it. A challenge/redirect window pops up based on the 3DS 2.0 or 3DS 1.0 transaction details, and Aria submits the challenge/redirect form to end step 2.
Step 3: Execute authorize_3dsecure_m with the <proc_pymnt_id> value (from step 1), perform the authorization, and verify the API result to complete the 3ds authentication-based authorization.
Regarding Processor/Gateway Integration Certifications
If you previously implemented a custom payment processor/gateway integration, you likely completed a certification process with that processor/gateway. Aria maintains certifications with each of the processors with which it integrates. Though you may wish to certify your Aria-related processor/gateway integration before going live on Aria, this is not necessary and could add significant time and Services costs to your Aria implementation process. Please consult your Aria Implementation representative for more detailed information.
Regarding Processor- and Gateway-specific Information
All Processor- and Gateway-specific information provided on Developer Central exists as publicly accessible information from the respective companies, and is presented here for your convenience. We update this information from time to time as necessary.