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.
Note: The UTC format is the date/time standard used across all BaaS APIs.
The BaaS suite of APIs are built upon the following core APIs:
The Enrollments API allows Partners to:
Enroll a new user
Create the new user’s account
Create the new user’s payment instrument (card)
The Users API allows Partners to:
Update current user information
Retrieve current user information
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
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
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
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
The ATM Locator API allows Partners to:
Search ATM locations
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
The Retail Locator API allows Partners to:
Search for nearby retailers who allow cash reloads using:
SwipeReload
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
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
This Healthcheck API reports the availability of the downstream service.
None
If the GET request is successful, the following response message is returned along with a 200 HTTP status code.
OK
{
"healthCheck": {
"serviceName": "string",
"status": "string",
"totalTime": "string",
"waitTime": {
"additionalProp1": "string",
"additionalProp2": "string",
"additionalProp3": "string"
},
"dependencies": [
"string"
]
},
"responseDetails": [
{
"code": 0,
"subCode": 0,
"description": "string",
"url": "string"
}
]
}This Healthcheck API determines if Green Dot servers are reachable.
X-GD-RequestId (String, Header) - Required. Contains a request identifier in UUID format.
If the GET request is successful, the following response message is returned along with a 200 HTTP status code.
OK
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.
Call should retry after a randomized wait time of 1 - 1000 milliseconds
Call should retry after a randomized wait time of 1000 - 5000 milliseconds
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.
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.
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
API is locked.
409
4091
The call timed out waiting for an active request to complete on an overlapping call.