Tips & FAQ
      Back to home
      1. Knowledge base
      2. Integrations
      3. Tips & FAQ

      Sending payment requests using “customPR”

      The "customPR" service is intended to allow full customisation and control over a payment request, via API. Each payment request will be uniquely created using objects available on the Merchant account (i.e. products, bank accounts, logos), and requires all settings that are to be applied to the payment request be provided in the API request.

      There are few default values applied, exceptions to this are noted in the API documentation (typically for technical/process needs rather than customer experience).The service is designed to be flexible in it’s validation rules, and always will seek to create a payment request. There are fields that are not required to create a payment request, but may be necessary to enact a true white-label experience. If not provided or invalidly provided, these fields will be discarded and the payment request will be created with a warning provided in the API response.

      No template is required when using this service, however it is possible to provide the template ID for an “API Custom” template type that the Merchant may have configured within the web interface. Providing such an ID on a payment request allows the Merchant to apply access controls to this payment request for Merchant users within the FlipPay web interface.

      FAQ

      What's the difference between this service and "simplePR"?

      "customPR" does not require a request template to be configured in the Merchant account - the payment request is created entirely within the API request.

      All customisation features are available to access and set with this service (e.g. custom fields, payment page branding, etc).

      What's an API Custom template?

      This is the one time you may want to consider providing a template ID in the "customPR" service - refer to this article for details. This is an advanced feature, used by Merchants with complex use cases that mean they're using their FlipPay account with multiple teams, over integrated systems and via the FlipPay web interface.

      When should I use this service?

      • When the integrated system is providing more of a white-label experience in itself
      • When the integrated system is seeking to manage the payment process
      • When there are many variables to the structure of payment requests, or many types of payment requests to send
      • When the Merchant does not want to manage payment request templates in the FlipPay web interface
      Fundamentally - this service requires more effort and thinking in how the integrated system will enable settings to be provided or managed per Merchant, but does not require the Merchant to do anything in the FlipPay web interface. It allows full control of payment requests via API, with no dependencies other than requiring an active Merchant account. If this model sounds ideal for the payment use case, consider using the "customPR" service.

      Can I create recurring payment types with this service?

      Yes.