Merchant Application API v2

The Merchant Application API allows you to submit applications for merchants to obtain credit card processing services.

iPayment Web Handoff Workflow

Return to the main Merchant Application v2 API documentation page.


This usage scenario utilizes iPayment's web application to interact directly with the merchant to gether their informaiton and have them complete the application. In this scenario the API is used to create the application and optionally pre-populate some data.

Swagger Documentation

Please note that API calls depicted in the below diagrams (green boxes) are shown using the name of that method as it appears in our Swagger Documentation. Please refer to the Swagger Documentation for details.

Start New Application (required)

Posting a DocumentSave data structure to the "Create Application" endpoint starts a new Merchant Application. The SalesRepID and PackageID are required, all other fields are optional. Starting a new empty application that contains no data can be useful because it will issue a unique ApplicationID Guid. If any validation or other errors occur during the creation process an HTTP error result code will be returend along with a ValidationResults structure containing messages describing the problem(s) that occurred. Please note that a new Applicaiton will not be created and an ApplicationID will not be issued if an error occurs or the data provided does not pass validation.

Load Existing Application (optional)

This depicts the process of retrieving an existing Applicaiton that was created previously in order to view, make changes or perform actions upon it.

Continue Application (optional)

After an Application has been created its data can be fetched (returning an Application data structure) and updated (using the DocumentSave data structure). When performing an Update the information in the ApplicationSave structure will overwrite all information from prior Create or Update calls (documents are not affected). Please note that once an applicaiton has been progressed furhter through the workflow (such as moving it into states for obtainnig a signature) its data becomes read-only and "Update Application" can no longer be called.

Document Actions (optional)

After an Application has been created it may contain Document attachments. Through the API the list of documents associated with an Application can be obtained and indivdiual documents can be downloaded (for viewing), uploaded (added) or deleted. Each attached document has a Document Type which indicates its purpose and media type. Some docuemnts are automatically generated by the system at certain points during the workflow. Documents that have a DocumentType which is automatically generated by the system can not be deleted. When adding documents, the encoding used must be Base64 (not raw binary).

Handoff to iPayment (completion)

In this workflow once an application has been created and pre-populated as needed by the partner the merchant will be directed to iPayment's web application (which can be branded) to enter their information and complete the submission process.

To perform the handoff call the "Direct Merchant to iEntry" endpoint. If any data currently in the application is not valid or there is insufficient information for the handoff to occur an HTTP error response will be returned along with validation messages indicating the problem(s). If the handoff is successful an email will be sent to the merchant with directions and a link to complete the application process. A unique numeric PIN code will also be returned from the API call which will need to be provided to the merchant by the partner.