Payment Source's PSIComm API supports multiple distribution channels, including self-serve kiosks, attended POS terminals (POS), and Host to Host. The billing system supports postpaid accounts and prepaid eCash accounts. You should know which kind of billing account you will be using before completing your development integration.
Integration development of your client application can be done to various levels or completed in phases. For example:
It is recommended the client side have a response timeout of 20 seconds.
You should discuss the integration and launch plan with your Payment Source contact before starting development.
In order to make a call to PSIcomm, there are several things a developer must understand. We recommend learning the following concepts in order:
Learn about Product Types and Store GUI's.
Learn about the files contain the information about the products including voucher content.
Decide on which protocol you want a make a call to PSIcomm.
Implement the API call that relates to the Product you want to sell and which Store GUI it will use.
The Payment Source system caters to many types of clients, from personal handheld devices to centralized servers. Integrations are to be customized to fit the business needs.
All products are on the PSInet system are associated to a six character “product” code and a “value” code which are to be included in all transaction requests. These codes and values can change over time and are communicated using a “product file”. New files are scheduled for release approximately four times a year, or more frequently if there is an update which cannot wait until the scheduled release. New product file versions are to be checked for availability at least once per week. Daily is recommended.
The product file contains the codes and values available on the system, as well as instructional text and terms and conditions. The product file is a standardized file provided to a large group of Payment Source customers and/or client types and is not typically customized. Payment Source must approve the final output generated by all integrators meets the needs of the end user and any requirements by the product suppliers.
Note that it is necessary to support Canadian French if products are offered to Quebec users.
Some products can be requested and held in your local inventory (pre-fetched) before sale to the end user (e.g. most mobile pins) and some products must be transacted live (e.g. real-time top up). It is recommended all products be requested from the PSInet server real-time.
If the integration is between the PSInet system and a central distributor or single server (i.e. server to server) it is only necessary to use one billing (or “merchant”) account. If Payment Source is to have individual arrangements with those using the client solution, each user will have their own merchant account. Each merchant account can have one or many client (or “terminal”) IDs, depending upon the number of physical machines, locations, and transaction volume by the merchant. Individual Terminal ID's are required to process transactions in sequence. If large volumes do not easily allow for sequential processing, more than one Terminal ID is to be used.
Depending upon the arrangement, the unique transaction number generated by PSInet may need to be shown to the end user. If Payment Source is not providing support to the end user, this transaction number does not need to be displayed to the end user, but must be provided to Payment Source for any support inquires.
The client’s reporting, reconciliation and support processes must be considered to ensure the developed solution meets the business requirements. Requirements are to be provided before development begins.
PSInet test system credentials and developer support for the PSInet test system are provided after the integration specifications are agreed. During development the developers should maintain an open dialogue with the PSInet development support team. Payment Source can provide assistance validating results, provide test scenarios, and recommend test cases.
After both the client and Payment Source agree development is complete, formal certification is required. Payment Source provides the client a test script to be completed.
Production transactions are allowed after certification has passed, the production systems configured, and a few production control transactions have been validated.