<<Back

Overview of Banking-as-a-Service (BaaS) Suite of APIs

Welcome to the Banking as a Service (BaaS) APIs provided by Green Dot Corporation. Here at Green Dot, we understand that quality APIs must cater to two distinct audiences: The Partner and their developers. Partners must be able to rely on our APIs ability to keep up with the demands of their processes, while their developers need clear and concise documentation along with a user-friendly design that will seamlessly integrate into any of their products.

The goal of our BaaS suite of APIs is to provide our partners with the ability to easily expand their financial services in a cost-effective way. Our APIs provide you (the Partner) with the core banking services infrastructure you need to seamlessly integrate into your current application(s), the ability to launch additional financial products and the ability to expand into additional markets. We do this by providing you with a customized related set of products, services, accounts, users, activities, and transactions for your brand owning organization in a secure manner.

The BaaS APIs are RESTful, meaning they utilize HTTP verbs (GET, PUT, POST) to perform functions on objects. Specifically, GET is used to retrieve, PUT is used to update, and POST is used to create. Our APIs are developer-friendly and use JSON format along with OAuth2.0 authorization. We also offer partners access to our public swaggerhub, upon onboarding.

Core APIs

The BaaS suite of APIs are built upon the following core APIs:

Enrollments

The Enrollments API allows Partners to:

• Enroll a new user

• Create the new user’s account

• Create the new user’s payment instrument (card)

Users

The Users API allows Partners to:

• Update current user information

• Retrieve current user information

Accounts

The Accounts API allows Partners to:

• List the transactions for a specific account

• Retrieve account details

• Retrieve user’s primary account balances

• List available account statements for a specific period

• Verify user identities through Know Your Customer (KYC) and Green Dot

Payment Instruments

The Payment Instruments API allows Partners to:

• Create a new physical payment instrument for users

• Create a new virtual payment instrument for users

• Retrieve user’s payment instrument details

• Set and reset ATM pins for users

• Replace payment instruments for users

• Request initial physical payment instruments for users

• Activate payment instruments for users

Transfers

The Transfers API allows users to:

• Transfer their funds to and from their internal accounts (purses)

• Transfer their funds to and from their external accounts

• Deposit checks into their accounts

ATM Locator

The ATM Locator API allows Partners to:

• Search ATM locations

Customer

The Customer Care API allows Partners to:

• Create customer support cases for scenarios where Green Dot is responsible for providing

• Allow customers to create support cases for Green Dot agents to view and resolve

Retail Locator

The Retail Locator API allows Partners to:

• Search for nearby retailers who allow cash reloads using: o swipeReload o eCash

eCash

The eCash API allows Partners to:

• Provide users with the ability to create and use barcodes to add cash to their accounts at participating eCash locations

• Retrieve a list of participating eCash partners associated with a program code

• Retrieve the active barcodes associated with a user account

• Retrieve specific barcode details

Webhooks

The Webhooks API allows Partners to generate test webhooks and provides users with the ability to:

• Receive notifications of events (activities) occurring on their account

• Transaction Events

• Statement Ready Events o Account Updated Events

• Interest Paid Events

• ACH Transfer Events

• Failed Transfer Events

• NOC Alert Events

• User Updated Events

• Card Updated Events

• Check Updated Events

• eWallet Events

• Bill Payment Events

• Paper Check Events

BillPay

The BillPay API allows Partners to:

• Setup a payee to receive bill payments from users

• Provide users with the ability to schedule future bill payments (including one-time and recurring payments) with the payee

• View and manage bill payments

Idempotency

Idempotency is when a partner makes the same API call with the same input parameters, multiple times, and the same response is returned each time. Basically, an identical request should return an identical 20 result when done twice, two thousand, or two million times. With the BaaS API, idempotency is implemented using the requestId. For example, a successful POST /enrollments API call with the same requestId will always produce and return the same results.

If the requestId is the same, the payload must also be the same. If the payload changes, then that is a different request. If an operation was incomplete when an idempotent call was made, then; assuming no additional failures or errors occur, the operation will be completed as originally intended

A common scenario for an idempotent call is when an initial API call either fails or times out. The client may not know if it succeeded, failed, or partially completed. A successful idempotent call will complete the operation and return a result, just like if it was fully completed in the first call.

In the BaaS APIs, true idempotency has been implemented with the POST /enrollments endpoint.

Example

In response to a HTTP Status 503, the caller should retry their call, up to 3 times with exponential backoff, by sending in the exact same request. The exact same request is needed to allow for idempotency logic implementations and for request resumption/completion in the event of a transient error.

Retry 1

• Call should retry after a randomized wait time of 1 - 1000 milliseconds

Retry 2

• Call should retry after a randomized wait time of 1000 - 5000 milliseconds

Retry 3

• Call should retry after a randomized wait time of 5000 - 30000 milliseconds

If all three retries are done and the error is still received, the call should be considered failed. The call should not be made again automatically. New requests should be generated and submitted for further attempts. Note: A retry should not be attempted on a HTTP Status 400 or 500.

API Locking

The following endpoints support API locking by preventing overlapping API calls. If multiple calls are made to the endpoint, the API will be locked based on the value noted in the tab.

UTC

The UTC format is the date/time standard used across all BaaS APIs.