Mock Services

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.

KYC

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.

• {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 WYor- 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 +11236547890or- 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 Issuance

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 card

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 card

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

4. Click Import on the next screen.

   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": 199,
       "mcc": "5697",
       "merchant_name": "My Test Store",
       "merchant_id": "234575675"
     }'
   

   plaintext

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

Request attributes

Default behavior for merchant attributes

The three merchant attributes are optional. When omitted, the mock service applies consistent defaults:

Simulate different Card Brands

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.

Shipping address variations

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.

• 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 Processing

Card payment methods

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.

Unhappy path statuses

3D-S scenarios

Bank payment methods

Unhappy path statuses

Simulate an ACH Return

An ACH return reverses a previously originated transaction (for example, insufficient funds or a closed account). Use this to test how your integration handles returned transactions end-to-end —the simulated return file is processed through the same flow as in production.

Note: This step is NOT needed in production.

curl --location --request POST 'https://mock.snd.alviere.com/generateReturn'
--header 'Content-Type: application/json'
--header 'x-api-key: '
--data-raw '{
"transaction_uuid": "f84a40dd-3fbc-4478-bf89-ca5b30a95272",
"return_code": "R01"
}'

A successful request returns 204 No Content. The return is processed asynchronously; the
transaction will reflect the return shortly after.

Request attributes

Supported return codes

Eligible transaction types

LOAD_FUNDS, PAYMENT, WITHDRAW_FUNDS, BANK_DEBIT

Errors

Simulate an ACH Notification of Change (NOC)

A Notification of Change is distinct from a return: it does not reverse funds. It is a
notice from the receiving bank telling the originator that something about the account should be corrected for future entries (for example, a new account or routing number). Use this to test how your integration handles RDFI-issued corrections.

curl --location --request POST 'https://mock.snd.alviere.com/generateNoc'
--header 'Content-Type: application/json'
--header 'x-api-key: '
--data-raw '{
"transaction_uuid": "f84a40dd-3fbc-4478-bf89-ca5b30a95272",
"change_code": "C01",
"corrected_data": "987654321"
}'

A successful request returns 204 No Content. The NOC is processed asynchronously through the same flow as in production.

Request attributes

Note:

corrected_data is passed through as-is; the mock service does not validate its format
against the change code.

Supported change codes

Eligible transaction types

LOAD_FUNDS, PAYMENT, WITHDRAW_FUNDS, BANK_DEBIT

(same eligibility rules as ACH returns)

International transfers

For international transfers, the following test scenarios are supported.

Fail Scenarios

Bank payout 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 Loading

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",
            "barcode_data" : "1234567890"
          }
        }
      }
    },
    "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",
            "barcode_data" : "1234567890"
          }
        }
      }
    },
    "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 checks

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:

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 checks

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:

The transactions suitable for testing this workflow include the following:

• INTERNATIONAL_TRANSFER

• BANK_DEBIT to local Beneficiaries