Mobile Applications (React Native)
This guide is for Platform API v2011101. For guidance on the newest version, see Connectivity Integration Guides.
In the following steps, we’ll use the React Native Widget SDK to embed the Connect Widget into your mobile application. The Connect Widget manages gathering end user’s credentials and connecting to end user’s accounts to fetch the financial data you need. This guide starts from the beginning and demonstrates how to set up the SDK, configure the connect widget, and read the financial data you need in order to verify information for payments.
The overall flow for Deposit Account Opening is as follows:
- Download and Setup the SDK
- Create a user and configure the Connect Widget to use Account Aggregation, Instant Account Verification, and Account Owner Identification.
- Import the Widget into your application via SDK.
- Enable the user to interact with the widget.
- List account and transaction data to learn more about your end user's finances.
- List account numbers to verify account and routing number for account funding and to identify potential fraud.
- List account details to verify available balance and the account status for account funding.
- List account owner details to identify potential fraud.
- Fetch and list balance data if you plan on moving money or funding accounts after you initially verify the account details.
Download and Set Up the SDK
Our React Native Widget SDK is available on our Gitlab. You’ll first need to download it and follow the React Native Widget SDK Guide to properly embed it in your application. The React Native Widget SDK guide instructs you to set up the SDK, but there are still several steps you need to do to ensure the Connect Widget is configured to fetch the data you want for payment verification. If you’re not using React Native, review instructions in our Embedding the Connect Widget in a WebView guide.
Create a User
A user represents your end user in the MX Platform. Make a request to the Create User endpoint (POST /users).
We recommend that you include a unique id of your choice with the request. You may also include metadata, such as the date the user was created or the end user's name. Don't include any sensitive information here, such as credentials.
None of these parameters are required, but the user object can't be empty. We recommend that you always set the id parameter when creating a user.
In the response, the API gives each new user an MX-defined guid (or user_guid when appearing outside the user object). Between your id and the guid, you can map between your system and ours. You'll need the user guid for nearly every request on the MX API, at least when using basic authorization.
Configure the Connect Widget by URL by Proxy
When you set up the Widget SDK, you’ll need to configure the Connect Widget to fetch the data you want using either a proxy or generating a Widget URL. The following example demonstrates the request for a Widget URL using the Platform API. For more information on using a proxy, review the Generate a Widget URL section of our Web Widget SDK guide.
Widget URLs are one-time use. You must fetch a new widget URL each time you load the widget.
In summary, configure the Connect Widget for the following:
mode: verificationinclude_identity: trueinclude_transactions: true
Setting the mode to verification fetches account number and routing number.
If your use case requires access to account owner information like name and address, you can use the include_identity parameter. This tells the Connect Widget to fetch account owner data after account verification is complete.
If your use case requires account and transaction history, use the include_transactions parameter. This ensures that we fetch account details and transaction data at the same time that we fetch account and routing number.
Setting the mode to verification limits the widget search results to institutions that support Instant Account Verification. Setting include_identity further limits search results to institutions that support both IAV and account owner identification.
Import the SDK and Render the Widget
Once the steps above have been completed, import components from the @mxenabled/react-native-widget-sdk package and render them in your application.
_12import React from "react"_12_12import { ConnectWidget } from "@mxenabled/react-native-widget-sdk"_12_12export default function App() {_12 return (_12 <ConnectWidget_12 onLoaded={() => console.log("Connect Widget Loaded")}_12 url="https://widgets.moneydesktop.com/md/connect/..."_12 />_12 )_12}
Interact with the Connect Widget
The Connect Widget asks end users to search for an institution, provide their credentials, and determine which account they’d like to verify. It may also handle multifactor authentication or any errors that occur.
As the end user interacts, you can listen to postMessage events by passing callback functions in the widget options object to the class. The option names use the following naming scheme. For example, the mx/connect/selectInstitution event is made available via onSelectInstitution in the ConnectWidget class.
Refer to this document for a list of events and their payloads.
| Event | Prop |
|---|---|
| Widget | on<event name> |
| Entity | on<entity><action> |
You’ll need to listen for a couple important event messages:
- member status updated which gives you the member GUID and the current
connection_status. - member connected tells you that the member has been successfully connected and you can move on to the next steps.
- If you’re using
include_identity(which means using IAV, then an account owner identification), the member connected event message will not trigger until after both processes are complete — that is, after the account owner identification is done. - Alternatively, if the end user closes the widget early or some other problem occurs before you see a CONNECTED status, you can use the
member_guidto immediately check the member’s connection status via the API.
Read the Account Data
Get a list of all the account data associated with your user by making a GET request to the list accounts endpoint.
You can see in the following example that the user has 21 accounts associated with it. If you look at the type field, there is a checking account, a savings account, a credit card account, and several others. Also, there is information on the balance of each account, such as APY for credit accounts or payment due days. You won’t always get values for every field; that depends on the data provider and the information available from the financial institution in question.
Make a note of the account GUID for the checking account associated with our test member: ACT-8e6f92c8-1491-42ce-8bf6-c309e9531530. We’ll need this to list all the transactions associated with the account.
Read Transaction Data
With the account GUID you found in the last step, make a request to the list transaction by account endpoint. Notice from the pagination object in the response that there are 176 transactions in this account and that the endpoint returned the first 25 of these.
You can access the rest of these transactions by making another request and specifying the number of records you want to access (valid values range between 10 and 100) and specifying the page you’d like to see. You can pass these parameters in the request URL to same endpoint as demonstrated in the following example. The pagination object in the response now shows 100 records per page and a current page of 2.
Read the Account Numbers
By configuring the connect widget to run in verification mode and include_identity, the Connect Widget can complete IAV and Account Owner Identification after the end user interacts with it. When verification is complete, retrieve account and routing numbers. We have two endpoints for this: list account numbers by member and list account numbers by account. We show the first here.
- If MX has both an account number and a routing number for at least one of the member’s accounts, that information is returned. No information is returned for accounts that are missing a value for one or both of these fields.
- The account number returned from this endpoint may be a Tokenized Account Number (TAN). See the section on TANs for information on dealing with these properly.
Read the Account Details
Before using the account numbers you’ve just gathered for things like ACH transfers, read the account details by making a GET request to the read account endpoint.
Read the account’s details to confirm that:
- The
available_balanceshows sufficient funds. - The account is still open:
is_closed: false.
This helps prevent ACH returns.
Read Account Owner Details
After you've connected, list account owner information using the list account owner endpoint to review identity-related data. Information returned depends on what is available from the institution the end user connected to. You'll need the user_guid and member_guid to pass the request.
_10curl -i -X GET 'https://int-api.mx.com/users/USR-fa7537f3-48aa-a683-a02a-b18940482f54/members/MBR-7c6f361b-e582-15b6-60c0-358f12466b4b/account_owners?page=1&records_per_page=10' \_10 -H 'Accept: application/vnd.mx.api.v1+json' \_10 -u 'client_id:api_key'
Fetch and Read Balance Data for Future or Delayed Payments
Account and routing numbers can be used for things like ACH transfers for as long as the account is still open, so there is no need to use IAV again for the account. However, information about the available balance in that account can become out of date within a few hours.
Before using these numbers again in the future (or if you wait a while to use them after the initial verification) run a balance check to get the latest available_balance before you initiate a payment or transfer. This prevents errors related to insufficient funds or closed accounts. For more information on Balance Checks, review our Balance Check product guide.
a. Fetch Account Balance
Make a POST request to the check balances endpoint.
Aggregating balance data takes some time, so check on the status of this process. Initially, you should see the is_being_aggregated field return with true.
b. Check the Status of the Balance Process
The balance check is complete when the following state is reached. You may need to check the status multiple times using the read member endpoint.
connection_status: CONNECTEDis_being_aggregated: falsesuccessfully_aggregated_atupdates to the current time.
c. Read the Account Details Again
Check to see that available_balance is sufficient for your purposes and that is_closed is false. Make a GET request to the read account endpoint.
We suggest you add a Balance Webhook in the Client Dashboard. We provide webhooks that send HTTPS POST callback requests to the URL of your choice. This webhook notifies you when new balance data is successfully returned. Note this webhook does not trigger member-based actions. For more information on webhooks, click here.