Mobile payment standardized platform

Each mobile carrier has its own API. The single platform took into account their differences:

●  Support for HTTP and non-HTTP API.

●  Multiple authentication methods

●  Multiple format encoding.

●  Multiple interaction patterns: send a request-read response, send a request-download response, send a request-wait-receive response.

In order to translate all of them into a single standard format, high-level standardization was applied. OPTI found common patterns to organize the variable APIs in less than ten general concepts. The most important concepts were the user (the millions of end clients) and the procedure (an action performed by or for a user, such as a payment, balance-check or refund). Intermediary concepts were used to make the transition from the standard high-level structure to the low-level variable APIs. The standardization used UML in a structured SQL database, and noSQL data stores for non-critical data.

The payment platform's purpose was to bring the user from their first access to the completed payment. We took into account:

●  Regulatory differences (country laws)

●  Payment-schedule differences: one-time charging, daily charging, weekly charging etc.

●  Balance checking.

●  Product granularity: One of the thousands of product variants should be delivered to the user based on what he paid.

OPTI extended the high-level standardization in the data structure to the programming code used. Each mobile carrier could be assigned a programmer. But common standards and a mandatory common design are specified.

The payment platform has to deal with millions to billions of users and procedures. Our top priorities were:

●  Payment speed

●  Payment regularity

●  Distributed nature

●  Natural separation of resources

●  Resources economy

OPTI measured and computed the impact of each procedure on the hardware theoretically, choosing time-tested technologies. A scheduling engine was developed from scratch. We also put business logic in the database itself (i.e. using stored procedures and database triggers)

Any payment system requires the highest level of reliability and traceability:

●  Payment history

●  Atomicity and reversibility

●  Ease of inspection

●  Documentation and ease of on-boarding in place.

OPTI designed a noSQL data store separated from the standard structured SQL data store to record the entire process history. All API interactions are also logged. The project documentation includes the programming standards, the detailed programming structure and the API interaction details.