Testing in the Sandbox Environment

Testing User/UserIntent States

Quickstart with Examples

To jumpstart integration testing, we have provided example payloads that can be leveraged to create user intents that will land in specific statuses.

When creating a user intent you can select one of the following examples which will pre-populate the parameters with values that will produce the desired status:

📘

Note when using one of the examples above, you must provide your own values where specified. For example, include your email where you see YOUR_EMAIL, and a real testable phone number where you see YOUR_PHONE. Please refer to Further Details for specific information on repeated testing using the same email and phone number.

Further Details

When Astra processes a User/UserIntent profile for security and KYC assessment, a resulting User Status for the User/UserIntent will be applied. To test these scenarios, you can use the following options for the User/UserIntent details (phone, first_name, ip_address, etc.)

📘

Note that you may only attempt to create 3 UserIntents per email address. If you reach this limit while creating UserIntents in your Sandbox Environment, you will receive an error.

📘

Note that you may create as many UserIntents with a single phone number as you'd like. However, once this UserIntent becomes converted_to_user and a User profile is created, this phone number cannot be used for another User profile. If you attempt to authenticate with a phone number that is already associated with a User profile, you'll automatically be logged into the User profile that the phone number is associated with. To free up this phone number, you'll need to delete the User profile via the User tab in your Developer Dashboard.

📘

There is a “logout” button for rejected user sessions in Sandbox Environments so you can more easily test different User statuses. This enables you to quickly clear a persisting rejected user session, whether intentionally or unintentionally created. Note that this feature is not available in production.

Phone Number

The UserIntent object as well as the Authentication step in our OAuth Module require a US-based phone number that can receive SMS text messages. For testing purposes, we recommend having more than one US-based phone number available as this will make it easier for you and your team to manage test Users. If you do not have more than one US-based phone number, we recommend creating virtual US-based phone numbers via services such as Google Voice or Twilio. These virtual numbers have the abilty to recieve SMS messages.

It's important to note that due to persisting User sessions, if you do use the same phone number for two different Users/UserIntents, it is likely that you'll be logged in as the previous User/UserIntent upon authenticating.

If you are unable to receive SMS messages from Astra, check the following:

• Is your phone a US based mobile phone capable of receiving SMS messages? Landlines cannot be used in Sandbox or Production as SMS messages can only be delivered via Text.
• Does the phone number you are authenticating with match the phone number of the UserIntent? These two numbers must match.
• Are you located outside of the United States? If yes, we recommend that you use a virtual US based phone number with an IP address that is within the United States.
• Are you on a VPN? If so, we recommend you turn off your VPN.
• Are your Chrome Settings blocking 3rd party cookies? If yes, we recommend adjusting your settings.

Scenario 01: Approved

• Create a UserIntent with any phone number, except for phone number in Scenario 02.
• The UserIntent status will be approved
• Note: approved means the User/UserIntent is in good standing

Scenario 02: Rejected

• Create a UserIntent with the following phone number: 1-202-555-1111
• The UserIntent status will be rejected
• Note: This phone number cannot be used for authenticating. There is no corresponding SMS / OTP for this phone number and it can only be used to create a rejected UserIntent.
• Note: rejected means the User/UserIntent failed our security and/or KYC check and the end-user has been rejected from using the Astra Platform

📘

You can also create a rejected status for a UserIntent if you use the following DOB: 1970-01-01.
Note that any DOB containing January 1st (YYYY-01-01) will result in a rejected UserIntent status.

First Name

Scenario 01: Approved

• Create a UserIntent with any first name, except for the two outlined in the scenarios below
• This will result in a successful authorization and the end-user will be able to proceed with actions such as connecting bank accounts and creating routines and transfers

IP Address

Scenario 01: Approved

• Create a UserIntent with any IP Address, except for the three outlined in Scenario 02.
• We recommend that you use your real IP Address, which can be found here: https://whatismyipaddress.com/
• This will result in a successful authorization, which will result in an approved user intent status and enable the end-user to proceed with the remaining OAuth steps.

Scenario 02: Rejected

• Create a UserIntent with one of the following IP Addresses listed below. Each of these test IP addresses will trigger a response, which will result in a rejected user intent status and prevent the end-user from proceeding with the remaining OAuth steps.
  • 127.0.0.1
  • 127.0.0.2
  • 127.0.0.3

📘

You can also create a rejected status for a UserIntent if you use the following DOB: 1970-01-01.
Note that any DOB containing January 1st (YYYY-01-01) will result in a rejected UserIntent status.

Document Submission

As a part of Astra's KYC process, certain Users / UserIntents may be placed in a document status, requiring the submission of a government-issued ID. Accepted forms of identification include licenses, ID cards, and passports.

Deleting Users

Our Sandbox Environment is designed to be as close to production as possible. This means certain actions in the Sandbox environment are not as flexible as one might expect. For example, you can only use one unique phone number per user, since in production, this relationship is one to one.

For testing purposes, we do allow you to delete users in the Sandbox Environment, which is something you cannot do in production.

To delete a user, navigate to the Users table, locate the user you wish to delete, and select the delete (trash can) icon. Deleting a user will delete all of the user's data from the system.

However, there are several reasons why you may not be able to delete a user. If you are unable to delete a user, review the following information:

• Refresh your dashboard: your developer dashboard has an authorization token which periodically expires. Try refreshing the User table and try again.
• Pending Transaction: if a user has any pending transactions, the transactions will need to process before you are able to delete the user. Locate the user and navigate to the Transfer table to see if any transactions are pending.
• Different OAuth Client: If a Sandbox user also belongs to different OAuth Client (a different Sandbox Env.), only the original OAuth Client who added this user has the ability to delete them. If a user belongs to a different OAuth Client, you'll receive the following error message when attempting to delete them: "User was not created by provided client". If this happens, consult with your teammates to see if someone else on the team created another sandbox environment.

Issuing Test Debit Cards

If you are integrating Astra's Instant Funding solution, you may create client-issued debit cards via our POST /v1/cards endpoint using a test BIN provided by your card issuer. You'll need to reach out to your designated Astra Integration contact to register the BIN with your client. You may also leverage the below example debit cards for the same purpose or to test connecting an external debit card via our SDK.

📘

When adding these test cards, provide any CVV and expiration date. Each unique CVV and expiration date combination should result in a unique card added to the system.

Test cards that result in status:approved

Visa Debit Card Example

• Type: Visa
• Card BIN: 400005
• Card #: 4000056655665556
• CVC: Any 3 digits
• Exp. Date: Any future date, e.g. 03/29

Visa Debit Card Example 2

• Type: Visa
• Card BIN: 424242
• Card #: 4242424242424242
• CVC: Any 3 digits
• Exp. Date: Any future date, e.g. 04/29

Visa Debit Card Example 3

• Type: Visa
• Card BIN: 411111
• Card #: 4111111111111111
• CVC: Any 3 digits
• Exp. Date: Any future date, e.g. 04/29

Mastercard Debit Card Example

• Type: Mastercard
• Card BIN: 520082
• Card #: 5200828282828210
• CVC: Any 3 digits
• Exp. Date: Any future date, e.g. 05/29

Test cards additional scenarios

For testing specific scenarios around cards, we have the following list of test card numbers that will be created with the specified details:

📘

This group of test cards for additionanl scenarios must be added by a user in order to get the desired result. This means the card must be added (1) via the Add Card Web SDK (/cards/connect) or (2) via API with added_by_user:true.

Flagged Debit Card Example

Results in a card with status: flagged

• Card #: 4005637396666873
• CVC: Any 3 digits
• Exp. Date: Any future date, e.g. 02/25

Rejected Debit Card Example

Results in a card with status: rejected

• Card #: 4000447849978767
• CVC: Any 3 digits
• Exp. Date: Any future date, e.g. 02/25

Pending Debit Card Example

Results in a card with status: pending

• Card #: 4000729255518207
• CVC: Any 3 digits
• Exp. Date: Any future date, e.g. 02/25

Not Pull Enabled Debit Card Example

Results in a card with pull_enabled: false

• Card #: 4005149937656157
• CVC: Any 3 digits
• Exp. Date: Any future date, e.g. 02/25

Not Push Enabled Debit Card Example

Results in a card with push_enabled: false

• Card #: 4009647527112891
• CVC: Any 3 digits
• Exp. Date: Any future date, e.g. 02/25

Inactive/Unauthorized Debit Card Example

Results in a card with status: rejected. Any card that cannot be authorized will result in a rejected status.

• Card #: 4000954619713209
• CVC: Any 3 digits
• Exp. Date: Any future date, e.g. 02/25

Not Address Verified (AVS) Debit Card Example

Results in a card with address_verified: false. This means the address on file at the issuing bank does not match what was provided in the card payload.

• Card #: 4000129288836314
• CVC: Any 3 digits
• Exp. Date: Any future date, e.g. 02/25

Credit Card Example

Results in a card with card_type: credit

• Card #: 4012692502496690
• CVC: Any 3 digits
• Exp. Date: Any future date, e.g. 02/25

Sandbox Phone Numbers

Astra provides 5 out-of-the-box test phone numbers, unique per Sandbox client, that enable you to manage, and test multiple UserIntents and User Profiles without needing to use your personal phone number and or create virtual phone numbers. In addition, they allow the user to circumvent the multi-factor authentication process, which makes for a more seamless testing experience.

How to Enable Test Phone Numbers:

• Navigate to your Astra Dashboard
• Click into the Dashboard tab
• Scroll to the bottom of the page
• Click the toggle to enable Sandbox Test Phone Numbers
• Select “Save Changes”

📘

Sandbox phone numbers cannot be used in Production.

📘

You cannot use Sandbox phone numbers from a different Sandbox client to Authenticate.