Further considerations

Depending on your integration, there might be some additional things you might want to consider. E.g. some operations require direct API calls by nature.

Mapping requests and notifications

With full integration, think about what kind of meta data you want to pass for payment requests, in order to process the notifications efficiently. Consider things like invoice id, transaction id, subscription id, client id etc. If you are doing limited integration, make sure meta is compatible and the process with main integration is agreed upon. Notifications are sent always to the original integration and it needs to be able to cope with the meta.

With limited integration, ask the main product what meta needs to be included when doing payment requests for them. Remember, all the notifications are always delivered to the main product and to the limited integration product. The meta is defined by the main product and subject to changes, so agree on how you will be notified of such changes. NHP does not intefere with the meta data.

Tokenized cards and recurring payments

If payment methods for a shopper have been tokenized and saved during a payment, it’s a good idea to show them on the shopper’s (i.e. client of clinic) page inside the PMS. The clinic personnel must be able to remove the tokenized cards from the Payment Gateway when requested by the shopper. This can be done through checkout-ui, or from PMS using an direct API call.

For subscription based recurring payments, you would want to store the tokens inside the PMS and call the token payment API to charge the payments from the shopper.

Data & Privacy

Remember, that data you include in the API calls / checkout parameters, will be passed to external payment service provider(s) as it is. You should carefully consider, what information you include. You should never include any personal or sensitive information. Remember this especially with online payment requests with fields like description and line items.