This GET operation returns a list of Merchant Applications in the system based upon the parameters provided. Caution should be used on the range of dates supplied as a long running query and large results can be unintentionally generated.

Parameters:

Name

Required

Description

Format

Example

startDate

Yes

The filter beginning date

YYYY-MM-DD

2017-08-01

endDate

Yes

The filter ending date

YYYY-MM-DD

2017-09-26

agentName

Select only this agent’s name

TEXT

RalphOscar

status

Select only applications with this status.

TEXT

Allowed Values:

New: An application that has been newly created

OutstandingElecSign: An application that has been submitted for electronic signature by the merchant. At this stage, the merchant has not signed the application yet. Electronic signatures are not available through the API; however, for partners that use both the UI and the API, applications entered through the UI will appear in the API, and vice versa.

CompleteElecSign: An application that has been signed by the merchant and is ready to be reviewed and submitted for boarding

Submitted: An application that has been submitted for boarding

Canceled: An application that has been cancelled by the sales agent. Cancelling applications is not available through the API.

PendingMerchantReviewLink: An application that has been submitted to be reviewed and partially completed by the merchant. This functionality is not available through the API.

MerchantCompletedReviewLink: An application for which the merchant has completed Merchant Review.

OutstandingUnderwriting: An application that has been submitted for underwriting by an external service and is pending its response prior to being submitted.

startIndex

Page number to start on

Integer

5

pageSize

Number of records to return on a page

Integer

25

Example:

/Application/CA/List?startDate=2017-08-01&endDate=2017-09-26

Response Content:

Success or failure based upon the response code returned.

A successful response includes a JSON file listing the Merchant Applications based upon the parameters supplied. An example of a single application returned is shown below:

This PUT operation replaces the existing Merchant Application data “payload” in the system for the unique Application ID provided or if the unique Application ID does not exist and the createIfNew parameter is set to “true”, adds the Merchant Application data “payload” into the system for the unique Application ID.

Parameters:

Name

Required

Description

Format

Example

Application ID

Yes

The unique Application ID to overwrite the “payload”

Unique ID

02abc16-fdf7-406e-8c60-b514Bde23d84

“payload” file

Yes

The complete “payload” data file for this Application ID

JSON “Payload” layout

See appendix for an example

strict

Pre-validates the Merchant Application data using the same rules as the PreSubmitValidations operation

Text

true

createIfNew

If the unique Application ID does not exist, creates a Merchant Application for the unique Application ID

Text

true

Example:

/Application/CA/02abc16-fdf7-406e-8c60-b514Bde23d84

Response:

Success or failure based upon the response code returned.

If strict is “true” and failure occurs, then error information is provided. For example if the JSON file contained "CorporateState": "ZZ", then an error code of 400 is returned and the Response Body contains:

This POST operation first validates the Merchant Application data “payload”, just like the PreSubmitValidations operation, for the unique Application ID. If there are no validation errors, the Merchant’s Application data “payload” and documents are sent to our onboarding system.

Note: This operation is considered to be synchronous as the operation waits until a success or failure response occurs before the operation is complete. This operation can take a considerable amount of time and you should carefully consider the use in your application design. The SubmitAsync operation should be considered instead, if your application design can be structured to avoid waiting for a response.

This POST operation, based upon the unique Application ID, schedules the Merchant Application data “payload” to be validated and if there are no validation errors, the Merchant’s Application data “payload” and documents are sent to our onboarding system.

This Asynchronous scheduling operation does not wait for the success or failure response. The response for this operation is returned to the URL provided in the requestCallback parameter.

Any other file extension will cause the API to respond with a 401 Fail response. Only one document file can be uploaded at a time, but this operation can be repeated as many times as needed to provide all the supporting documents required.

The file must be uploaded in the multipart/form-data format with an attachment named “file”. For example: