The Alviere Sandbox Environment operates independently of external third-party services typically involved in executing transactions. To bridge this gap, we have integrated mock services and scenarios that replicate the production environment experience. These simulated examples are designed to facilitate your testing process, helping you to prepare for various situations that may arise when customers start using your services.

Please be aware that not all of these scenarios may be necessary or compatible with your particular program. It's important to consult with your Alviere implementation team to identify which scenarios are relevant to your needs. For instance, in the case of KYC, if your program is limited to the IDENTITY and SANCTIONS Processing Stages, only those specific test conditions can be utilized. Attempting to use test conditions from other Processing Stages will lead to the Account status changing to ACTIVE, provided all required data attributes are submitted, as these conditions might not be pertinent to your program's setup.

KYCCopied!

During the Account onboarding process, we created scenarios to simulate different Processing Stages of the identity validation process. This is accomplished by submitting specific data attributes during the

Create Account

requests. The table below outlines the conditions that should be used to trigger the different account statuses.

Note that data attributes submitted in the request outside of the conditions below will result in all processing stages being automatically accepted where the Account status results in being

ACTIVE

.

Processing Stage	Test Conditions	Account Status and (Status Reason)	Action required to advance the entity to the next stage
FRAUD	email_address contains: deny_ For example: {name}+deny_1@anydomain.com {name}+deny_123@anydomain.com	REJECTED	N/A
FRAUD	email_address contains: manual_ For example: {name}+manual_1@anydomain.com {name}+manual_123@anydomain.com	MANUAL_REVIEW	Accept / Reject the Account in MANUAL_REVIEW
ADDRESS	Following postal_code and state combinations: postal_code starts with 82007 state equals WY or postal_code starts with 28748 state equals NC	PENDING_USER (INVALID_ADDRESS)	Update the Address with another postal_code and state combination
ADDRESS	Address line_1 or line_2 match regex (PO box variants): ^(((p[\s.]?[o\s][.]?)\s?)|(post\s?office\s?))((box|bin|b.?)?\s?(num|number|#)?\s?\d+) For example: PO Box 123 P.O. Box 123	PENDING_USER (INVALID_ADDRESS)	Update the Address with another other line_1 or line_2 address
IDENTITY / IDENTITY_OPTIONAL_SSN	Requires all variables in the combinations below first_name equals Ben last_name equals Wyatt ssn ends in 3333 date_of_birth equals 1974-01-01	PENDING_USER (INVALID_NAME)	Update the Account with any other combination of consumer information
IDENTITY / IDENTITY_OPTIONAL_SSN	Requires all variables in the combinations below first_name equals Un last_name equals Born date_of_birth YEAR equals 1900or 1974 Any ssn should be provided	PENDING_USER (INVALID_DOB)	Update the Account with any other combination of consumer information
IDENTITY / IDENTITY_OPTIONAL_SSN	Requires all variables in the combinations below: first_name equals Leslie middle_name equals Barbara last_name equals Knope ssn ends in 6788 date_of_birth equals 1975-01-18 phone_number equals +11236547890 or first_name equals Ella last_name equals Phone ssn ends in 666	PENDING_USER (INVALID_PHONE)	Update the Account with any other combination of consumer information
IDENTITY / IDENTITY_OPTIONAL_SSN	Requires all variables in the combinations below first_name equals Jeremy last_name equals Clarkson or ssn ends in one of 9009, 9010 or 1906	PENDING_USER (INVALID_SSN)	Update the Account with any other combination of consumer information
IDENTITY_OPTIONAL_SSN	To test a Consumer that provides a Mexican ID or Passport, no SSN provided, and the system does NOT find a SSN match. Requires all variables in the combinations below: first_name equals James last_name equals Smith All other information (i.e. address, phone, etc…) should be provided including the documents (i.e. MC_DOCUMENT_FRONT, MC_DOCUMENT_BACK, SELFIE)	ACTIVE	N/A
IDENTITY_OPTIONAL_SSN	To test a Consumer that provides a Mexican ID or Passport, no SSN provided, and the system finds a SSN match. Requires all variables in the combinations below: first_name equals James last_name equals May All other information (i.e. address, phone, etc…) should be provided including the documents (i.e. MC_DOCUMENT_FRONT, MC_DOCUMENT_BACK, SELFIE)	PENDING_USER (REQURES_LAST_4_SSN)	Update the Account with any ssn value (4 or 9 digits)
DOCUMENTS / DOCUMENTS_OPTIONAL_FULL_SSN	last_name equals Undocumented	PENDING_USER (INVALID_DOSSIER)	Update the Dossier with a generic drivers license front and back as provided below
DOCUMENTS / DOCUMENTS_OPTIONAL_FULL_SSN	last_name equals invalidDOB	PENDING_USER (INVALID_DOB)	Update the Account with date_of_birth equals 1980-01-29
DOCUMENTS / DOCUMENTS_OPTIONAL_FULL_SSN	last_name equals invalidName	PENDING_USER (INVALID_NAME)	Update the Account with a different last name
DOCUMENTS / DOCUMENTS_OPTIONAL_FULL_SSN	last_name equals ExpiredDoc	PENDING_USER (EXPIRED_DOCUMENT)	Update the Account with a different last name
DOCUMENTS / DOCUMENTS_OPTIONAL_FULL_SSN	last_name equals Verifications	MANUAL_REVIEW (INVALID_DOSSIER)	Accept / Reject the Account in MANUAL_REVIEW
DOCUMENTS_OPTIONAL_FULL_SSN	ssn only contains last 4	PENDING_USER (REQUIRES_DOSSIER)	Submit a dossier/documents
DOCUMENTS_OPTIONAL_FULL_SSN	last_name equals InvalidClassificationCountry or InvalidCountry	PENDING_USER (COUNTRY_OF_ISSUANCE_MISMATCH)	Update the Account with a different last name
DOCUMENTS_OPTIONAL_FULL_SSN	last_name equals CountryNotSupported	PENDING_USER (COUNTRY_OF_ISSUANCE_NOT_SUPPORTED)	Update the Account with a different last name
SANCTIONS	last_name equals Badguy	MANUAL_REVIEW	Accept / Reject the Account in MANUAL_REVIEW

Card IssuanceCopied!

When a card is created it will flow through various statuses until it becomes

ACTIVE. The core statuses follow this path:CREATED →

PROCESSING → … → READY_TO_ACTIVATE → ACTIVE

Below is an example of the Alviere Portal showing three different Non-Reloadable Prepaid Debit Cards in various statuses (i.e., PROCESSING, READY_TO_ACTIVATE and ACTIVE). The card status field will change in the Portal as the card advances through the various stages in Production but in Sandbox, the card cannot advance through all the Statuses automatically since the system is not connected to external production environments.

Simulate activation of a cardCopied!

To simulate what will occur in a production environment requires a few extra API calls. Here is how to advance the card to make it

ACTIVE

:

1. Open PostMan and navigate to Import

2. Click on the Raw Text menu option

3. Copy and paste the cURL details below to advance the card status from PROCESSING to READY_TO_ACTIVATE. The card_uuid field should be updated with the card you want to advance to the next processing stage.

4. Click Import on the next screen

5. Click the Send button

6. A successful update will result in a response of 200 Success

7. To activate the card, use the Activate Card endpoint. Note: the last 4 and the expiration date can be obtained in the Portal by going to the Cardholder’s Issued Card section, locating the card and clicking the “eye” under Actions. A successful response will not have an error message displayed.

curl --location --request POST 'https://mock.snd.alviere.com/shipCard' \ --header 'Content-Type: application/json' \ --data-raw '{ "card_uuid" : "94fdd7cf-9c8c-4996-a852-4dda59153568" }'

Notes:

• This step is NOT needed in production.

• The steps above outline the process using Postman but you can use any utility to execute these requests.

• Before this cURL can be issued the card status has to be in either SET_TO_EMBOSS or PROCESSING. If the card status is CREATED the process above will not work.

Simulate swiping a cardCopied!

Now that the card is active you can use the SwipeCard request to generate a card transaction.

Note: This step is NOT needed in production.

The steps below outline the process using Postman but you can use any utility to execute these requests.

1. Open PostMan and navigate to Import

2. Click on the ‘Raw Text’ menu option

3. Copy and paste the cURL details below to simulate swiping a card and click Continue

   curl --location --request POST 'https://mock.snd.alviere.com/swipeCard' \ --header 'Content-Type: application/json' \ --data-raw '{ "card_uuid" : "b053ccd1-6f93-46c2-8384-68d4a040ca08", "amount" : 1.99 }'

4. Click Import on the next screen.

   

5. Update the card_UUID with your card and the amount with the transaction value

6. Click the Send button

7. A successful update will result in a response of

   200 Success

8. You can see below the transaction is shown in Portal with the Status =

   PROCESSING_PAYMENT

Simulate different Card BrandsCopied!

During the card creation process for Card Issuance Create Card , you can create cards from different brands. The table below outlines the conditions that should be used to create cards from different brands.

Test Conditions	Card Brand created
firstName = "Mestre"	MASTERCARD
firstName = "Vision"	VISA
firstName = "Baymax"	AMEX
firstName = "DISCO"	DISCOVERY

Shipping address variationsCopied!

When a physical card is shipped, it is possible that the post office will return the card to the sender. To simulate returned mail you can use the following data attributes when submitting a

Create Card

request.

Test Conditions	Card Status
Shipping Address: line_1 equals 703 Lisbon Ave postal_code starts with 71762 state equals AR or line_1 equals 124 Main st postal_code starts with 99901 state equals AK or line_1 equals 567 Park Ave postal_code starts with 36535 state equals AL	RETURNED_MAIL

Card and Bank ProcessingCopied!

Card payment methodsCopied!

Test cards

In order to test different card scenarios, our sandbox environment requires the use of a known and valid card number therefore we provide various test cards for your use. In addition, we provide the ability to simulate transaction failures and delays. The following sections outline what we have available for your use.

We provide various test cards for various scenarios for your use. You can use the Payment methods Create Card endpoint to create a card payment method.

Note: Even though our Sandbox Environment is not connected to external services, you should never use a real card number.

Card Number	Card Network	Card Sub-network
4111111111111111	VISA	CREDIT
4000000760000002	VISA	DEBIT
4001370077777777	VISA	PREPAID
6011000990139424	DISCOVER	CREDIT
6011111111111117	DISCOVER	DEBIT
6011000991300009	DISCOVER	PREPAID
371449635398431	AMEX	CREDIT
378282246310005	AMEX	DEBIT
378734493671000	AMEX	PREPAID
5403879999999997	MASTERCARD	CREDIT
5152537170792358	MASTERCARD	DEBIT
5105105105105100	MASTERCARD	PREPAID

Unhappy path statuses

Status	Test conditions
DELETED	Use the "Delete card" API endpoint
FAILED	Create a card with a zip code of less than 5 digits or more than 9 digits

3D-S scenarios

Test data	Test outcome
Transaction amount: $69.31	Transaction status equals FAILED, status_reason equals 3DS_NOT_ENROLLED
Transaction amount: $81.45	Transaction status equals FAILED, status_reason equals 3DS_SYSTEM_ISSUE
Transaction amount: $81.46	Transaction status equals FAILED, status_reason equals 3DS_ERROR
Transaction amount: any other	Transaction status equals PENDING, status_reason equals 3DS_AUTH_REQUIRED

Bank payment methodsCopied!

Unhappy path statuses

Status	Test conditions
DELETED	Use the "Delete bank account" API endpoint
FAILED	Create a bank account using an invalid routing number

International transfersCopied!

For international transfers, the following test scenarios are supported.

Fail Scenarios

Test data	Test outcome
Transaction amount: $5.00 or $10.00	Transaction status equals FAILED

Bank payout :Bank transfer failed after pushing the funds

• Requirements:

  • Funding method -> CASH: destination amount must be 10000 or 20000 for both MXN and COP currencies (in USD: $5.0 or 10.0, for a default exchange rate of 0.05).

• Outcome: After 15 seconds (this period is ONLY for testing purposes) the INTERNATIONAL_TRANSFER will become FAILED due to failure to transfer. A REFUND transaction will be created in status PENDING, with status_reason REQUIRES_REFUND_METHOD.The refund_method parameter needs to be set via the refund transaction endpoint thereafter for the refund to be processed correctly.

Cash payout : Beneficiary Fails to Collect Funds

• Requirements:

  • Funding method -> CASH: destination amount must be 10000 or 20000 for both MXN and COP currencies (in USD: $5.0 or 10.0, for a default exchange rate of 0.05).

• Outcome: After 15 seconds (this period is ONLY for testing purposes) the INTERNATIONAL_TRANSFER will remain in COMPLETED. A REFUND transaction will be created in status PENDING, with status_reason REQUIRES_REFUND_METHOD.The refund_method parameter needs to be set via the refund transaction endpoint thereafter for the refund to be processed correctly.

Cancellation scenarios

The Sandbox environment allows clients to simulate and test different scenarios for canceling international transfers. Below are the flows you can test, along with the required conditions for each:

Bank payouts

1. Canceling a Transaction Within the 30-Minute Period

• Description: This is the default behavior. Transactions can be canceled as long as the 30-minute cancellation window has not expired.

• Outcome: The transaction is successfully canceled.

2. Canceling a Transaction After the 30-Minute Period (Cancellation accepted)

• Requirements:

  • Funding method -> WALLET, BANK_PM, CARD_PM: destination amount must be one of (7600 || 13100) for both MXN and COP currencies (in USD: $3,80 or $6,55, for an default exchange rate of 0,05). This will allow the transaction to be canceled successfully.

  • Funding method -> CASH: any amount can be used for this scenario.

• Outcome: The transaction is successfully canceled, even though the 30-minute window has elapsed.

3. Canceling a Transaction After the 30-Minute Period (Cancellation rejected)

• Requirements:

  • The destination amount must be 13140 (in MXN or COP).

    • Equivalent to $6.57 USD, assuming a default exchange rate of 0.05.

• Outcome: The cancellation request is rejected by the payout provider.

Cash pickups

1. Cancellation Happy Path

• Requirements:

  • Funding method -> WALLET, BANK_PM, CARD_PM, CASH: destination amount must be one of (7600 || 13100) for both MXN and COP currencies (in USD: $3.80 or $6.55, for a default exchange rate of 0.05). This will allow the transaction to be canceled successfully.

• Outcome: The transaction is successfully canceled

2. Cancellation Request Rejected – Cash Not Picked Up by Beneficiary

• Requirements:

  • Funding method -> WALLET, BANK_PM, CARD_PM, CASH: destination amount must be 13140 cents in MXN/COP (in USD: $6.57 for an exchange rate of 0.05).

• Outcome: Cancellation request is rejected (API returns 400).

Scenario 3: Cancellation Request Rejected – Cash Already Picked Up

• Requirements:

  • Funding method -> WALLET, BANK_PM, CARD_PM, CASH: destination amount must be any amount outside of the following list: 7500, 7600, 11160, 13000, 13100, 13140, 10000, 20000.

• Outcome: Cancellation request is rejected (API returns 400).

Cash LoadingCopied!

When a cash load transaction is initiated, it flows through various statuses. The core statuses follow this path:

CREATED→ PROCESSING_PAYMENT→ COMPLETED

In the Sandbox environment, cash load transactions are simulated since the system is not connected to external production environments. The mock service allows you to test the cash load functionality using barcodes.

Simulate Cash Load with Barcode

To simulate what will occur in a production environment, follow these steps using Postman or any API client:

1. Open Postman and navigate to Import

2. Click on the Raw Text menu option

3. Copy and paste the cURL details below to simulate a cash load transaction

4. Update the barcode_uuid with your generated barcode via the create barcode API and set the desired amount

5. Click Import on the next screen

6. Click the Send button

7. A successful update will result in a response of 200 Success

curl --location 'https://mock.snd.alviere.com/cashloadWithBarcode' \ --header 'Content-Type: application/json' \ --data '{ "barcode_uuid" : "f84a40dd-3fbc-4478-bf89-ca5b30a95272", "amount": 123.12 }'

To simulate a successful cash load transaction, follow these steps:

1. Ensure your barcode UUID is valid and hasn't been used before, and belongs to a CHECKING wallet

2. Set an amount that meets the minimum requirement ($5 USD)

3. Send the request as shown in the example above

Example Transaction Response

After a successful cash load, you can retrieve the transaction details which will look like this:

{ "transaction": { "transaction_uuid": "776b2949-ac18-4238-98db-e1482207bc8f", "wallet_uuid": "6bff373e-f376-4af7-872a-8520756767e5", "account_uuid": "6bff373e-f376-4af7-872a-8520756767e5", "external_id": "db6e0e7d-e323-4258-8ce5-18090209d525", "transaction_type": "CASH_LOADING", "status": "COMPLETED", "description": "", "amount": 200, "currency": "USD", "type_details": { "payments_details": { "cash_loading": { "cash_loading_location": { "store_network_id": "7805446fa58cb76d059c828c3c0bda49", "store_name": "Dollar General", "terminal_id": "terminal-000" } } } }, "refunded": false, "disputed": false, "created_at": "2025-05-20T09:30:20.440433Z", "updated_at": "2025-05-20T09:30:20.440433Z", "metadata": { "customer_id": "CUST-83643", "device_id": "DEV-353", "transaction_id": "c3a30ab1-3649-4f66-8c3e-dfc105e428ff" } } }

To simulate a failed cash load transaction, follow these steps:

1. Use a barcode UUID which was used before

2. Set an amount that meets the minimum requirement ($5 USD)

3. Send the request as shown in the example above

Example Transaction Response

After the operation, you can retrieve the transaction details which will look like this:

{ "transaction": { "transaction_uuid": "776b2949-ac18-4238-98db-e1482207bc8f", "wallet_uuid": "6bff373e-f376-4af7-872a-8520756767e5", "account_uuid": "6bff373e-f376-4af7-872a-8520756767e5", "external_id": "db6e0e7d-e323-4258-8ce5-18090209d525", "transaction_type": "CASH_LOADING", "status": "FAILED", "description": "", "amount": 200, "currency": "USD", "type_details": { "payments_details": { "cash_loading": { "cash_loading_location": { "store_network_id": "7805446fa58cb76d059c828c3c0bda49", "store_name": "Dollar General", "terminal_id": "terminal-000" } } } }, "refunded": false, "disputed": false, "created_at": "2025-05-20T09:30:20.440433Z", "updated_at": "2025-05-20T09:30:20.440433Z", "metadata": { "customer_id": "CUST-83643", "device_id": "DEV-353", "transaction_id": "c3a30ab1-3649-4f66-8c3e-dfc105e428ff" } } }

Transaction Fraud checksCopied!

For transactions subjected to fraud checks during the authorization stage, specific amounts may lead to varying outcomes in the approval process for these transactions.

The outcomes can be seen described below:

Test data	Test outcome
Consumer email domain: @example.com Transaction amount: $33.34	Transaction status equals MANUAL_REVIEW
Consumer email domain: @example.com Transaction amount: $33.35	Transaction status equals FAILED

The transactions suitable for testing this workflow include the following:

• LOAD_FUNDS

• INTERNATIONAL_TRANSFER

• CARD_ISSUED_INITIAL

• WITHDRAW_FUNDS

• BANK_DEBIT

• PAYMENT

• WALLET_TRANSFER

• CHECK_DEPOSIT

Transaction Sanctions checksCopied!

For transactions subjected to sanctions checks during the authorization stage, specific amounts may lead to varying outcomes in the approval process for these transactions.

The outcomes can be seen described below:

Test data	Test outcome
Transaction amount: $5.56	Transaction status equals MANUAL_REVIEW

The transactions suitable for testing this workflow include the following:

• INTERNATIONAL_TRANSFER

• BANK_DEBIT to local Beneficiaries