Skip to Content
FrontendPosUI needs for POS

UI needs for POS

This will contain all of the elements needed for the POS UI (related to Moneris Go). The POS frontend will always communicate with PHPR, PHPR will be the only one to communicate with the moneris middleware, to centralize requests, avoid code duplication and for better security (sensitive credentials will most likely be saved in the ERP in a secret kvs or something).

Settings / Configurations page

There need to be a page where the merchant can enter configurations, like the ID of the device (saved in local storage), merchant ID, and other necessary informations. It can also contain some system/device requests to adjust merchant settings in the device. Avoid sensitive informations in that page, we can decide later on how to manage them depending on the needs.

Payments Moneris actions

Moneris (or any other payment solution) integration needs to be accessible from the payments inside an invoice, for example in the payments sidebox. It is also what the clients are used to, you are free to change it but the UX must be as good or better.

Example from PHPR:

Legacy sidebox for payments

Directly from the payments, everything is at most 1 click away.

The test transactions are for super admin, but they are not necessary, they simply target a different transaction url.

The reference/notes of the payments needs to be easily accessible, as they can be needed to get the reference of the payment for a refund, capture or void transaction.

Forms

Example of form (subject to change with Moneris Go):

Legacy form for payments

The most important thing is the amount and the type. The form must match the needs of the request, that will be sent to PHPR backend first to get all sensitive credentials that are not saved into the frontend, such as access token. (Subject to change if oauth authorization is needed).

Manual entry might be subject to change, this API seems a lot different.

Requests flow

Always pass by the POS backend API to communicate with the PHPR API, because we will validate CSRF and other things before sending request to PHPR.

Last updated on