Introduction

This section is a reference for the creation and management of accounts in the Netspend API.
The Netspend API endpoints are generally centered around accounts, and the people, cards, savings or other resources associated with them.

Essentially, an account:

Represents a spending account backed by affiliates of Netspend, subject to risk assessment, compliance, and regulation.
Is tightly associated with a particular configuration in the Netspend system, called a “account creation context”, that carries with it:
- The partner configuration is for
- Type of account, which is one of two types:
  - Demand Deposit Account (DDA): A deposit bank account where the funds in the account are available to the account holder without any advance notice to the financial institution (FI).
  - General Purpose Reloadable (GPR): A general purpose prepaid card that can be reloaded as needed; an alternative for people who cannot qualify for regular credit or debit cards. Does not support overdraft.
- 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

Notes:

Account configurations (also known as account creation contexts) are set up by Netspend on your behalf according to business level agreements made between you and Netspend.
Account creation contexts are then provided to you to reference when creating accounts for their end users.
You may have multiple account creation contexts for delineating different card and feature offerings depending upon the type of user; example: you may want to offer one type of card to the general public, but offer a different type of “employee perk” card (with different terms, features like savings, and so on) to your employees.

Almost all Netspend API features depend upon the existence of an account. See other documents for more information on each of those features; example: People, Cards, Sessions, Agreements, Document Requests, and Savings.

This part of the Netspend API reference focuses on the Netspend API account resource itself.

Account States

An account is linked to a financial spending account, which means it can undergo several risk assessment levels before activation. As illustrated below, an account has three possible states, and transitioning to an active state requires additional activities such as an ID check.

Note: An account can be in an active state but still be blocked from using some or all features.

Account Creation

Account creation depends upon the account creation context configurations negotiated and then created for you, as depicted in the endpoint details description below. You generally start with one type of account offering, but may eventually offer several. The diagram below shows a setup where you (partner) offer two kinds of accounts—one for public customers and one for your own employees.

When using the Netspend API to create an account, you have the option of specifying the ID for a specific configuration (the provided_id) or a parent account ID (parent_account_id), where the new account will inherit the configuration used when the parent was created.

Account Activation Workflow Steps

When an account is created, it is not immediately usable by most of the account-related endpoints in the system except for the session and people endpoints See Sessions and People for more information.

To get to the point of being active for use, a number of additional steps are taken, largely for risk avoidance purposes. The extra steps generally represent measures and checks taken to help minimize actual monetary losses to you and Netspend due to fraudulent activity that may occur through the accounts.

Possible Activation Steps

Note: The exact checks to be done are configurable.

Following table shows some of the possible activation steps that may be configured as required, or as follow-up steps if the initial activation steps are inconclusive.

Activation Step	Description	Document with More Info
Device validation	A prerequisite step before creating and activating an account. At various stages in account creation and activation, sessions need to be created, which necessarily validate the device from which requests are originating.	Sessions
Identity questions	Probing questions meant to verify the identity of a person. Account creation and activation generally relies on verifying the identity of the primary person using the account.	People
Expected use questions	Additional questions about account usage activity; example: what deposits are expected in the account per month.	People
Agreements	Require the user to accept agreements, which may include: - Account terms and conditions - Privacy terms - Electronic signature (eSign)	Agreements
Document requests	Usually a follow up step, require the user to upload documents, which may include: - Address verification - Identity verification (driver’s license) - Proof of name change - SSN document	Document Requests

How To Know What Steps are Needed

The account resource object itself, when queried from the Netspend API, will indicate what steps are remaining by way of its “workflows” fields.

Each workflow listed contains specific steps needed to satisfy the workflow need
Each step may include a link that points to an endpoint on the API that can be used to satisfy the step

Possible workflows for an account include the items in this table:

Workflow	Possible Step	Description
activate	activate_owner	The owner needs to be activated. People endpoints should be used to determine the owner’s workflow to resolve.
	expected_use (deprecated - see People endpoints)	Expected use questions need to be answered. People endpoints should be used to resolve.
	primary_person_kyc_approve	The primary person needs to pass KYC approval. People endpoints should be used to resolve.
	subaccount_person_kyc_approve	A subaccount person needs to pass KYC approval. People endpoints should be used to resolve.
remove_block	remove_block	At least one block on the account needs to be removed. To determine what the account is blocked on, similar to querying the workflows, the account object indicates what is blocked by way of the “blocked_features” field, which may list one or more of the following: all external_bank_transfers external_card_withdrawals p2p_transfers savings subaccount_transfers subaccounts

Account Closing

You can close only subaccounts through the Netspend API. Closing any other type of account, example: primary account, happens by way of Netspend customer service, and usually because of:

Fraudulent activity detected
Request by account holder

When an account is closed by customer service, the Netspend API sends a webhook “account.closed”, and you can choose how to manage the customer experience around it.

Sample Flows

Onboarding a New Account and Person

This diagram shows a potential flow where the session is gradually promoted from anonymous to account to person as the end-user progresses through an account creation process. Along the way, some agreements need to be accepted by the account holder in order to be in an accepted KYC state, which is a gating workflow step to activate the account. For more details on how to onboard a customer , see Customer Onboarding.