<<Back

BaaS APIs Overview

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: Our Partners 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 enable you, our partners, to easily expand your financial services in a cost-effective way. Our APIs provide you with the core banking services infrastructure you need to:

  • Seamlessly integrate into your current applications

  • Launch additional financial products

  • 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 use HTTP verbs (GET, PUT, POST) to perform functions on objects. Specifically:

  • GET is used to retrieve

  • PUT is used to update

  • POST is used to create

Our APIs are developer-friendly and use JSON format along with OAuth2.0 authorization. Upon onboarding, we also offer you access to our public Swagger hub.

Picture

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

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

ATM Locator

The ATM Locator API allows Partners to:

  • Search ATM locations

Customer Care

The Customer Care API allows Partners to:

  • Create customer support cases for scenarios, where Green Dot is responsible for providing tier 1 and tier 2 customer support on the Partner’s behalf

  • Customize User Interface for customer support

  • 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:

    • SwipeReload

    • eCash

eCash

The eCash API allows Partners to:

  • Provide users 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 enables users to receive the following types of notifications occurring on their account:

  • Transaction Events

  • Statement Ready Events

  • 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

  • Paper Check Order Events

  • Mail Tracking Events

  • Promotional Transactions Events

  • Adjustment Final Status Events

  • MRDC Check Deposit Events

  • P2P Transfers Events

  • ATM Pin Update Events

  • Auto Money Movement (AMM) Events

  • Changes to Recurring SCC Plans

  • Locked Identity Theft Account Activity

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, 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 as 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.

API Endpoint
Value
POST /enrollments
requestId , ssn
POST /purses
accountIdentifier
POST /interestRateTiers
accountIdentifier, userIdentifier
POST /paymentInstruments
accountIdentifier
PUT /paymentInstruments/{paymentInstrumentIdentifier}
accountIdentifier
PUT /lifecycleEvent
accountIdentifier
POST /transfers
userIdentifier – if available accountIdentifier – If userIdentifier is not available
POST /kycGates/idv
accountIdentifier ,userIdentifier

Response Codes

Scenario
Code
SubCode
Description
API is locked.
409
4091
The call timed out waiting for an active request to complete on an overlapping call.

UTC

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