The "simplePR" service is intended for simple or "low-integration" use cases, single use case merchants, high-volume / low-customisation use cases.
The service will create a payment request based on a "simple" type template already configured within a Merchant's account - you just need to provide the customer details, template ID, amount to be requested.
This is the easiest service to integrate with but does require a template to be configured within the Merchant account.
- If the template's settings are changed, the integration will not be affected.
- If you want to use a different template, or multiple templates, consider how the IDs for these templates will be handled in the integrated system (so that you're adding correct IDs to API requests)
The service only supports templates of the "simple" type, as configured in the web interface.
Typically, products enabled in these use cases should not require product fields, however the service does support provision of product fields if necessary.
The service does allow for redirections to be configured per payment request. Any setting applied via API will override redirections that may be set on the template already. If no redirection settings are applied via API and there are existing settings on the template, the template settings will be applied to the payment request.
FAQ
Why does this service only support "simple" type templates? What does this mean?
Request templates configured in the web interface are set as one of three types - simple, advanced, API custom.
"Simple" templates are intended for easy configuration of the most common requirements Merchants use. They also provide a fixed data model for a payment request that cannot be changed in the web interface, meaning the API service can also remain static.
Compare to "Advanced" templates in the web interface - these templates allow for custom fields and other settings to be created on the template, which can also be edited/changed by authorised Merchant users. Doing so could break integrated services designed to expect a set of custom fields.
In this way, the "simplePR" service will only work on "simple" type templates - if you provide a template ID for another template type, the service will return an error.
When should I use this service?
- When a Merchant wants to control the templates used to generate payment requests, via the FlipPay web interface
- When the integrated system will not be managing the settings applied to each payment request (the Merchant will be require to do so via the FlipPay web interface)
- When the integrated system is not providing a full white-label experience within that system - if the external system is simply sending payment requests which are then managed by Merchant users in the FlipPay web interface, it may be easier to use this service and minimise the work required to integrate with FlipPay
Fundamentally - this service requires very little effort to use in an integration, and will require a Merchant to configure/manage their request templates in the FlipPay web interface. If this model sounds ideal for the payment use case, consider using the "simplePR" service.
What can I configure in my requests using this service?
- You can enable/disable communications sent to the Customer, meaning FlipPay can send or not send the payment request to a Customer (if disabled, the integrated system would present the payment request URL to the Customer)
- You can add product fields if they're required by the product enabled on the template
- You can set redirections for successful/failed payment attempts
- You can request notifications (as configured in the template) to be sent to a webhook URL (and optionally secure that URL with a token)
Any other constraints?
Currently, the "simplePR" service only supports one-off payments - templates configured for recurring payment schedules are not supported via API, and will return an error if called.