Stripe

Last updated
Save as PDF

The Stripe payment gateway accepts subscription payments from direct integrations with card networks and also powers payments for software platforms and marketplaces.

Supported Features

Payment Methods
Authorization and Capture
3DS 1.0 and 2.0 Authentication
Minimal Authorization and Automatic Authorization Reversal
Tokenization
Refunds
Soft Descriptors
CIT/MIT
Fraud Scoring/Level 2 and 3 Payments Supported
Account Updater
Tokenized Credit Card Support for Smart Payments
Additional Smart Payments Features including 3DS
Bank Account Holder Type Support

Payment Methods

The following pay methods and card types are supported by Stripe:

Method ID Number	Method	Type
13	Tokenized Credit Card	Visa
		Mastercard
		Discover
		Discover Diners Club
		American Express
		JCB

Authorization and Capture

Stripe supports two-step payments, also known as “authorization and capture.” This process allows you to authorize a charge and wait to settle it later.

Authorization: Once the issuing bank (ie. the bank of the cardholder) has accepted the authorization, you have seven days to capture the payment. During this 7-day period, the payment is guaranteed by the issuing bank, so there’s no risk for a merchant to decline a payment that has been authorized over the past seven days.
Capture: When you’re ready to actually accept the payment, you’ll just need to make a second API call to capture the charge. By default, we’ll capture the total amount that was authorized.

The following APIs support this feature:

3DS 1.0 and 2.0 Authentication

To support the Stripe 3DS 2.0 flow, we have introduced a new option, "Payer Authentication Settings," in the Payment Gateway and Collection group UI screen.

3DS Termination URL—When using 3DS (1.0/2.0) in Aria, you must provide the Merchant Website URL at this field (for Payment Gateways and Collection Groups). This will be invoked when the shopper challenge is complete. Otherwise, the transaction will not be completed, and the Aria authentication API will return a validation error. For direct post, the value should be 'https://secure.<environment>.ariasystems.net/api/auth_3ds2_notification_receiver.php' (with the environment name specified by the client).

The Stripe 3DS authentication is a three-step process, as follows:

Execute the authorize_electronic_payment_m or update_payment_method_m api with credit card details, billing address details and <attempt_3d_secure> as 'true' to perform client authentication. The API will then 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.

Notes:

If the <attempt_3d_secure> input is passed as 'false', then the 3DS flow will be skipped and regular authorization will be invoked, so the following steps would not be needed.
If the supplied credit card is not-enrolled with 3DS and the <attempt_3d_secure> input is passed as 'true', then the 3DS flow will be skipped and regular authorization will be invoked, so the following steps would not be needed.

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; submit the challenge/redirect form.
Execute the authorize_3dsecure_m API with the <proc_pymnt_id> from Step 1, perform the authorization and verify the API result to complete the 3ds authentication-based authorization.

The following APIs support this feature:

Minimal Authorization and Automatic Authorization Reversal

Since Stripe currently only supports the tokenized credit card payment method (pay method = 13), Aria has introduced a processor-specific configuration Validate card on Token creation > Requires card validation in the UI for both payment gateways and collection account groups. If this configuration field is enabled, then Aria performs a minimal amount authorization when creating the token. The field appears below:
All credit cards are tokenized within Stripe. Therefore, Tokenized Credit Card (TCC) payment method is the supported payment we have implemented. Aria only permits the validate_payment_information_m API to operate $1 auth/minimal amount on a pre-existing payment method record (<seq_no> input alone) for <pay_method_type> 13 in Stripe. Otherwise, an error message is generated when passing pay_method=13 with credit card details in the validate_payment_information_m API.

Stripe also supports reversing pre-authorizations on credit cards outside of $1. After performing the authorization, click on Accounts > search for the account > Payments & Credits (left panel) > Current Authorization Reversals tab > Create a New Auth Reversal. All pending authorizations that can be reversed display on this screen.

Tokenization

Stripe supports secure encryption for credit card and bank accounts. An encrypted reference to Personal Account Numbers called a payment method ID is created and used for transaction processing.

Refunds

Aria allows refunds on a previously captured Stripe transaction up to 180 days after its capture. The success or failure of a refund is returned in our API response.

Soft Descriptors

The soft descriptor configuration allows for a transaction description to be shown on the buyer’s credit card statement. This field allows for a 22-alphanumeric-character item description when paying by credit card and up to 15-character description when paying by electronic check. These fields are normally passed via the API; however, they can be set in the UI at the payment gateway or collection group level. The soft descriptor will be passed only for authorization and payment actions.

The soft descriptor field appears as shown:

The following provides additional functionality details:

The complete statement descriptor is either a single static descriptor or the combination of prefix and suffix. The suffix is concatenated with the prefix, the * symbol, and a space to form the complete statement descriptor for the customer statement.
Aria is allowed to send only the suffix for statement descriptor (soft_descriptor) in the name of statement_descriptor_suffix (maximum of 22 characters), whereas the prefix is sent from the merchant account setting (either statement descriptor or shortened descriptor) in the client’s dashboard (check with Shawn/Integration that the dashboard is a Stripe/client responsibility).
Stripe truncates the account statement descriptor as needed to set the prefix value. If the account statement descriptor contains fewer than 10 characters, it is not truncated. The statement descriptor is formed based on the character length of the prefix and suffix.

Some examples appear below:

Prefix (static value from merchant settings)	Suffix (dynamic soft descriptor value from Aria)	Statement descriptor (displayed on customer's statement)
WWW.ARIASYSTEMS.COM	oct marathon	WWW.ARIASY* OCT MARATH
ARIA	oct marathon	ARIA* OCT MARATHON
WWW.ARIASYSTEMS.COM	-	WWW.ARIASYSTEMS.COM

Note: The statement descriptor must be 5-22 characters including the * symbol and the space, and cannot contain the characters <, >, \, ‘, “, or *.

The following APIs contain the soft descriptor customer service fields:

Cardholder-Initiated Transactions/Merchant-Initiated Transactions for Visa® and Mastercard®

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.

Account Updater

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:

payment_method.updated
payment_method.automatically_updated
payment_method.detached

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:

Field	Description
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.

Field

Description

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
Discover
Japan Credit Bureau (JCB)
Mastercard
UnionPay
Visa

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:

Tokenization
Authorization and Capture
Refunds
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.

Supported Cards:

American Express
Discover
Japan Credit Bureau (JCB)
Mastercard
Visa

Limitations:

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.

Cancel/Reverse Authorizations

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.

Fraud Scoring

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)

Soft Descriptor

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:

API
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 *.

3DS Support

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.

Notes:

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.

Impacted APIs for this functionality include authorize_3dsecure_m, update_payment_method_m, and authorize_electronic_payment_m.

Bank Account Holder Type Support

For Stripe, this field has been added to the following locations in the Aria UI (permitted values are Individual or Company):

Create Account UI
Payment Methods UI
Billing Group (primary and secondary) UI
Payments UI
Plan Assignment UI

Links

Stripe

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.