API Details

Making a Transfer

A simple workflow for making a transfer to an external bank account looks like:

1. Make a POST /customers/{customerid} request as documented at POST /customers to create a new customer. If holding an existing account, retrieve its AccountID from the Registration API.
2. Make a POST/customers/{customerid}/links/type/{fundingtype} request using CustomerID from the previous response to create a funding link. Make a second similar request to setup a destination link. If using a Green Dot bank account for either the source or destination, skip establishing that link.
3. Make a POST/transfers/{transferid} request using CustomerID from the previous response to create a funding source.
4. Make a POST/transfers/confirm/{transferId} request using TransferId from the previous response to confirm or void the associated Transfer. (This step is only used for a 2-phase commit or void Transfer Process).

Request Headers

Standard Headers

• accept: What the response should be formatted with. We currently support the following:
  • application/xml
  • application/json (Default)
• Accept-Encoding: gzip, deflate
• Content-Type: application/json;charset=UTF-8

Custom Headers

• requestid: The unique request ID generated by the client for transaction tracking. It is advisable to prepend the ID with the unique partner name. This header is optional for all APIs, except for POST/Transfer.
• endusersecurityid: The agreed upon unique Security ID of the End User. This header is used for fraud prevention and is a required value.
• enduserip: The IP address of the End User. This header is used for fraud prevention and is a required value.
• partneridentifier: Identifies the sender of the request. The value will be provided by Green Dot. This header is required if it is not an admin call. If it is an admin call, this is not required (the url is / admin/ xyz.
• apikey: This is an admin identifier/key. The value is “disbAdmin.” This is an optional header for non-admin calls but required for admin calls. If this header is populated, the caller needs to use an admin credentials to generate the authorization header. For all CRM calls, they can pass apikey along with the corresponding authorization header. If you are using version 1.2 and above, this is no longer used.
• x-gdc-authentication-method: Specifies the authentication method. This is used in version 1.2 and above. Values are:
  • Basic – 1
  • Oauth -2 (will be supported in the future)
• x-gdc-client-type: Specifies the client type. This is used in version 1.2 and above. Values are:
  • External – 1 (default)
  • Internal -2

Response Headers

Standard Headers

• date: The date and time that the response was sent (in "HTTP-date" format as defined by RFC 7231 7.1.1.2)
• content-type: What the request was encoded with. Currently we support:
  • application/xml
  • application/json (Default)

Custom Headers

• x-version: the format of the version string is: major.minor.build.revision, where:
  • build is the number of days since January 1, 2000 local time.
  • revision is the number of seconds since midnight local time (without considering time zone adjustments for daylight saving time), divided by 2. (https://msdn.microsoft.com/en-us/library/system.reflection.assemblyversionattribute.assemblyversionattribute.aspx)
• requestid: The same requestid passed into the request.

Common HTTP Status Codes

Common HTTP Status Codes

Upon receipt of any HTTP status codes, the Partner can either submit a GET/transfers/{transferId} to find out the status of the transaction or retry the transaction. If the transaction is retried, the POST/Transfer must be with the SAME TransferID so that idempotency is triggered and double-funding is prevented.

Common Response Codes

Upon receipt of any common response codes, the Partner can either submit a GET/transfers/{transferId} to find out the status of the transaction or submit a new transaction. The new transaction should include a DIFFERENT TransferID. Sending the transaction with the same TransferID will only trigger idempotency and result in the same original response.

Common Response Detail Codes

Detail Codes are designed to provide additional detail information about the associated parent response code being returned.

Field Standards

Endpoints

Prefix: https://[server]/gateway/[version]/

📘

The current version is 1.1

Error Response

When an error occurs, there will be an errors property with a list of errors applicable to the request

• errorcode: Green Dot error code.
• errordescription: Descriptive error message.

Example:

{
   "errors":[
      {
         "errorcode":1317,
         "errordescription":"Missing request id”
      }      
    ]
}