Guides

Customer Onboarding

Customer onboarding is the beginning of association of a customer with Netspend. This process involves a sequence of the following steps:

  1. Creating API access token
  2. Establishing customer and Netspend sessions
  3. Creating an Account
  4. Creating a Person
  5. Approving KYC
  6. Accepting Agreements
  7. Answering Expected Use Questions (applicable only in direct deposit accounts)
  8. Ordering and Activating a Card

It is vital to complete the above steps to onboard a customer. The below diagram illustrates the steps to be followed to onboard a customer.

Creating API Access Token

You, as a Netspend partner, need to authenticate and establish a partner-level session with the Netspend API for a secure and successful integration.

Netspend API employs OAuth 2.0 for authentication. To access the sandbox, API key and scret pairs are provided through Netspend Developer Portal. These pairs are utilized for generating access tokens, which are required to utilize the various endpoints within the Netspend API.

For detailed steps to authenticate in Netspend’s sandbox or production environment, see the Partner Authentication guide.

Netspend SDK

Netspend SDK is required along with the Netspend API, for integration with your mobile app. The mobile app regularly utilizes Netspend SDK for the tasks like data encryption and decryption, as well as for initiating microapps.

Netspend SDK is available in three different versions:

  • Android
  • iOS
  • Web

For native applications, SDK versions for Android and iOS are available. The Web SDK is available for web-based access. You can download the latest version of the required SDKs from Netspend Dev Portal.

Netspend provides an SDK id in the starter kit that you would need to use while initializing the SDK.

Establishing User Session and Netspend API Session

You need to initiate the following sessions:

  • User Session
  • Netspend API Session

Both these sessions are important for establishing a secure connection and for checking the features available to the customer.

User Session

User sessions are initialized through the Netspend SDK available in your mobile app. While establishing the session, the device data (or fingerprint) is collected. The Netspend SDK encrypts that data and sends it as a part of the user connection creation call. The Netspend system verifies the device using this data received in the encrypted form. The session connection is allowed only for authentic devices.

Netspend API Session

To establish a Netspend API session, three different forms are available:

  • Anonymous
  • Account
  • Person

When a person is new to Netspend, prior to initiating account creation, the session established from your mobile app to the Netspend API is anonymous. It shares only the data that is encrypted for the key shared. You can establish an anonymous session by making a request to the POST /sessions endpoint. However, you are advised to create an anonymous session only once while onboarding the new customer and create a person session as soon as the user logs in.

📘

A person session is important as all the allowed features such as Me to Me and Bank Transfer are connected to a person and hence to a person session.

To move from an anonymous session to a person session, make a request to GET /sessions/{session_id} to first get the session id and then the PATCH /sessions/{session_id} endpoint to add person details to the session.

📘

The header - ns-session-id is mandatory while making a request.

For more details on sessions, see the Sessions guide.

Creating an Account

After a user session is established, initiates the process to create an account using the Netspend APIs. To create an account, a provided_id is needed. All account contexts stem from a provided ID, either directly or by inheritance from a parent account provided context ID.

📘

Provided means configured by Netspend to identify a specific context.

An account is tightly associated with a particular configuration in the Netspend system, called an account creation context (account_context), that carries the following information with it:

  • Name of the partner
  • Type of account–DDA or GPR
  • Card brands, of the given type, available for order
  • Terms and conditions
  • Eligibility rules and requirements and the ability to use Netspend API features
  • The Netspend-affiliated backing bank
  • Fee schedules
  • Other program-related configurations

Account States

An account has the following possible states:

  • New–When an account is in “new” state, it implies that it is a brand new account and needs to be activated. For an account to be “active”, it is mandatory that the primary person has to
    • be KYC approved
    • accept all the agreements
    • answer expected use questions
      The account is in “new'' state until all these conditions are met. The activate workflow details out the steps needed for an account to move from “new” to “active” state.
  • Active–When an account is “active”, it is eligible for feature enrollments, cards orders, and financial transactions.
  • Closed–When an account state is “closed”, it implies that no account activity is permitted.

You can request to create an account through the POST/accounts endpoint. To move an account from the “new” state to an “active” state, make a request to the GET/accounts/{account_id} endpoint. This endpoint returns the profile and status information about an account using the account_id unique to each account.

After the account status is active, the “activate” workflow guides the next sequence of steps.

📘

Once the account status is active, Netspend sends an account activation webhook POST/account.created.

For more details, see the Accounts guide.

Creating a Person and KYC Approval

Once an account is created, you need to create a request to create a person as part of the onboarding process.

The basic information required to create a person is their first name, last name, the account they belong to, and their desired role in that account.

To create a person for a new or an existing account, you need to make a request through the POST/person endpoint. The encrypted_data body parameter contains personally identifiable information (PII) such as date_of_birth or government_id. The identity_context passed in the request body provides instructions on how to link the person. If the person is to be added to an existing account, you need to provide the account_id.

If sufficient data is provided in the request, the server performs an OFAC and/or KYC verification.

📘

A failed OFAC or KYC check does not cause the request to fail.

Once the request to create a person is initiated, GET/people/{person_id} endpoint is used to retrieve the details of the person.

After the person is created, a session is patched with the person_id, so the customer can perform bank transfers and other transactions on their account without the need to create a new session.

Accessing an Account

Once the account and a person is created, there are a few criteria to ensure that the person is able to access their account:

  • “status”: Whether a person is active or not.
  • “kyc_status”: Whether or not the person is blocked or rejected by Netspend’s KYC (Know Your Customer) assessment. Here a person can be in a “conditional” status, where some additional workflow steps may move the person into an “approved” status required to put the person into active status.
  • “ofac_status”: Whether or not the person is rejected for being flagged for fraudulent activity by OFAC (Office of Foreign Assets Control).

For more details, see the People and Know Your Customer guides.

Accepting Agreements

When a person is created, as part of account creation, agreements are displayed to the customer for acceptance. You need to take care of the interface provided to accept the agreements and receive confirmation from customers about the agreement acceptance and submit the acceptance to Netspend.

Customers are presented with three types of agreements during account onboarding. These agreements have to be accepted before the account is activated. These agreements are:

  • Card holder terms
  • e-Sign
  • Privacy policy

To get the links to these agreements and display them to the users, make a request to the POST /agreements/search endpoint using the provided_id. This search returns the links to the agreements (along with agreement_id which is used for further processing but not displayed to the customers) that are applicable to the customer.

You can then display these agreements to the customer to accept. To fetch agreements, make a request to GET /people/{person_id}/agreements endpoint using the person_id. Make a request to GET /agreements/{agreement_id} endpoint using the agreement_id to display details of individual agreements.

When the customer accepts the agreements, the person is created and the account is activated. The acceptance of each agreement is recorded by making a request to PUT /people/{person_id}/agreements/{agreement_id} endpoint using the person_id and agreement_id.

When the acceptance of all the applicable onboarding agreements is recorded, the person is created and the account is activated.

For more information see the Agreements guide.

Getting and Answering Expected Use Questions

📘

The "Expected Use Questions" information is applicable only for Demand Deposit Accounts (DDA).

As per the regulations, Netspend has to collect some information about customers like–occupations and salary range. This is presented in the form of a bank survey from which the required answers are collected.

To get a list of expected questions that are associated with a person_id, partners can make a request to GET /people/{person_id}/expected_use endpoint. When the customer selects or provides the answers, they are submitted to Netspend by making a request to PUT /people/{person_id}/expected_use endpoint for the same person_id.

Sample Questions

  1. About how much do you expect to deposit each month?
    • $2,000 and under
    • $2,000.01 to $10,000
    • $10,000.01 to $20,000
    • Over $20,000
  2. What is your occupation?
    • Accountant
    • Administrative Assistant
    • Administrator
    • Ag Manager
    • Architecture
    • Auditor
    • Bookkeeper
    • Broker
    • Business and Financial Operations
    • Carpenter
    • Cashier
    • Child Care
    • Clergy
    • Coach
      IT
    • Contractor
    • Customer Service Representative
    • Dentist
    • Doctor
    • Education
    • Electrician
    • Engineer
    • Executive
    • Farmer
    • Fire Fighter
    • Food Service
    • Hair Stylist
    • Health Care
    • Hotel/Motel
    • Insurance
    • Jeweler
    • Legal Occupations
    • Manager
    • Meat Packer
    • Musician
    • Nurse
    • Pharmacist
    • Postal Service
    • Protective Service Occupation
    • Real Estate
    • Salesperson
    • Self-employed
    • State/Government
    • Employee
    • Student
    • Teacher
    • Travel Agent
    • Truck Driver
    • Unemployed - income
    • Unemployed - no income
    • Veterinarian
    • Construction Worker
    • Production Worker

For more information see the People guide.

Ordering a Card

Now that an account and person is created, KYC is approved, and the account is activated. You can now move forward with a card order for the customer. The customer can order a physical card, a digital card, or a virtual card.

Ordering of a physical card takes a route through multiple endpoints. Let’s discuss that journey here.

Various available brands of cards are presented to the person as part of onboarding. To get and display these brand options, you can make a request to POST /cards/brands/search endpoint with person_id as part of the request. Based on the selection of a brand, the card can be ordered for the person. To order a card, make a request to POST /cards/physical endpoint. Provide account_id, person_id, brand_name, and address in the request. Once received, the customers activate their physical card. To activate the physical card, make a request to the PUT /cards/{card_id}/pin endpoint by providing card_id while making the request.

Virtual cards can be used for online transactions that require PAN. Virtual cards cannot be digitized. Digital cards do not have a PAN but they can be added to the wallet. To create a virtual card, you can make a request to POST /cards/virtual endpoint.

To create a digital card, create a request to POST /cards/digital endpoint. For any of these requests, provide account_id and person_id in the request.

For more details, see the Cards guide.

Feature Enrollment

Once the card is activated, customers will need funds in their accounts. So, after the cards are ordered, customers need to enroll in the money movement features like bank transfer, savings, and so on. For customers to enroll into these features, they need to fulfill the feature specific eligibility requirements.

For the detailed information on each of the features, see the Savings, Bank Transfers, and Me to Me transfers guide.

Updated about 1 year ago