The Merchant Application API allows you to submit applications for merchants to obtain credit card processing services.
The usage described in this section mostly applies to partners who will use the API to submit applications after they have gathered all of the necessary informaiton. This is typically direct system-to-system communication where the partner's backpend system calls into iPayment without a user being interactively involved.
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.
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.
This depicts the process of retrieving an existing Applicaiton that was created previously in order to view, make changes or perform actions upon it.
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.
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).
Once all of the necessary information has been saved to an Applicaiton and any required Documents uploaded the merchant's signature must be obtained in order to finalize and submit the applicaiton for processing. The system supports multiple ways of obtaining the signature, the methods relevant to this workflow are listed below.
One method of obtaining the merchant's signature is to have them physically sign the Merchant Processing Agreement. To do this call the "Submit for Applicaiton Signature" endpoint which will validate the application's data and, if valid, generate an unsigned copy of the agreement. Downlaod the generated, unsigned agreement and provide it to the mercahnt for their signature. Once the signed agreement has been obtained from the mercahnt scan it in and upload (attach) it to the application. Once the signed copy has been attached calls the "Submit Application for Processing" endpoint.
Please note that the merchant must sign the unaltered agreement that is generated by our system. Do not attempt to generate your own contract or alter the contract that is generated.
If the merchant entered their information using an interactive computer system (such as your own web application) you may be able to use our "click to agree" capability to have the merchant virtually sign the Merchant Processing Agreement. In order to use this method all information relevant the agreement including all rates & fees and the legal terms & conditions must be available to the merchant for reading. An additional check box or similar control labled something like "Accept terms and conditions" must be displayed to the user and they must specifically mark the box themselves to indicate their agreement. For specifics or exceptions please discuss this with your partner representitive.
Please note that all information contained in the Merchant Processing Agreement including all reates & fees plus the legal terms and conditions must be made available to the merchant prior to obtaining their virtual signature.