Honouring web interface access controls

FlipPay enables Merchants to configure access controls within the web interface, that can be optionally supported when creating payment requests via API

This article is only relevant in the scenario where a Merchant is accessing FlipPay via an integrated system and via the FlipPay web interface, and wants to enact access controls within the FlipPay web interface.  Supporting this requirement is easy to enact, but requires an understanding of the system behaviour - explained in this article.

When a Merchant's FlipPay account is provisioned, there are no access controls configured - all users created in the FlipPay account can access all payment activity, when logging in via the FlipPay web interface.

  • For Merchants only accessing FlipPay via API services (Introducer and/or 3rd party systems), access controls for their individual users is handled in the integrated system.
  • For Merchants only accessing FlipPay via the FlipPay web interface, the same default configuration applies however Merchants can create "user groups" to enable a simple level of access control
  • For Merchants accessing FlipPay via the FlipPay web interface and integrated API services (Introducer and/or 3rd party systems), Merchants can configure specific request templates related to user groups, to enable access controls within the web interface on payment requests generated via API services

Importantly, none of the configurations discussed in this article will prevent an API user from generating or accessing a payment request - they only affect the visibility of that payment request to web users via the FlipPay web interface.

User groups

Reminder: user groups are only applied within the FlipPay web interface.

User groups have users, request templates and hosted payment pages related to them. Users in the group are typically (exception for API/admin noted further) the only users who can create payment requests using related templates, and the only users who can access payment activity generated from these templates and hosted payment pages.

Merchants may encounter scenarios where they may need to control access for different user groups while accessing FlipPay directly and via integrated systems.

This is achieved by configuring users into user groups, enabling request templates for those groups, and providing template IDs in each payment request created via API.

  • By placing users and templates into groups, users in a group can only access the templates related to their group, via the web interface
  • By providing template IDs in API calls, FlipPay is able to automatically relate payment requests to groups, without the calling system needing to know the FlipPay user group configuration
  • Ignoring specific product restrictions, any integrated system can provide any valid template ID and FlipPay will create the payment request accordingly

Merchant API users

Integrated systems require an access token to create payment requests on a specific Merchant account - this token is generated when the Merchant creates an "API user" account.

The earlier summary applies well to the standard user accounts in FlipPay, however API user accounts behave differently. When user groups are configured in a Merchant account:

  • API users do not need to be placed in a group to have access to the group's templates - they will have access to all templates, objects and payment activity across the Merchant account
  • When API users are not placed in a group:
    • If the payment requests generated by the API user include a template ID - via the web interface, only web users in the group related to the template ID can access the payment requests
    • If the payment requests generated by the API user do not include a template ID - via the web interface, no web users in user groups will be able to access these payment requests (as they're not related to any template/user group)
  • When API users are placed in a group:
    • If the payment requests generated by the API user include a template ID - via the web interface, only web users in the group related to the template ID can access the payment requests (i.e. being in a group or not doesn't affect this scenario)
    • If the payment requests generated by the API user do not include a template ID, all such payment requests are visible to all web users in any group that the API user is a member of

Introducers

Introducers do not require an API user account to be pre-configured on a Merchant account - they have a separate authentication model enabled as part of their agreement with FlipPay to become an Introducer.

Request templates

In the scenario where the Merchant uses integrated systems and the FlipPay web interface, consider the following.

  • Within the web interface, there are 3 request template types:
    • Simple - a simple model with limited customisation available, used for high-volume low-complexity use cases
    • Advanced - mirrors the "customPR" API service, in that all settings on a payment request are available for configuration
    • API Custom - a reference template that can be used in the "customPR" service to relate specific payment requests to a user group, this template requires no configuration itself and exists solely as an ID that can be related to user groups, and referenced within the "customPR" service
  • There are 2 API services that can be used to create a payment request:
    • "simplePR" - must include a valid template ID from a "simple" type request template
    • "customPR" - may include a valid template ID from an "API Custom" type request template
  • If the integrated system is using the "simplePR" service, the Merchant must provide the relevant template ID which must be included in the API call - the payment request will be created per the template configuration, and only accessible to the user group related to the template.
    • The integrated platform should allow a Merchant to manage this template ID - consider if the template is later removed/replaced, or if multiple templates are used.
  • If the integrated system is using the "customPR" service, the Merchant should be optionally able to provide a template ID to be included in the API call - the payment request will be created per the API request, and only accessible to the user group related to the template ID.
    • "customPR" does not require a template ID
    • A payment request created via "customPR" without a template ID (as long as it's a valid API request) will always be created and function via API services, but may not be accessible to users via the FlipPay web interface if a Merchant configures user groups
    • Any type of payment request can be created via "customPR", and all can use the same "API Custom" template ID - all payment requests referencing this template ID will appear in the user group related to the template ID, no matter the type or content of the request
    • User groups and "API Custom" templates do not technically affect "customPR" requests or the integration with another system - they simply allow an integrated system to create payment requests that honour the FlipPay web interface access controls, if so desired

Wrapping up

Merchants who wish to apply access controls to their users with the FlipPay web interface, and have those controls applied to payment requests created via API, can do so via:

  • Configuring user groups
  • Adding web users and/or API users to user groups
  • Relating "simple" and "API Custom" templates to user groups
  • Providing template IDs in API requests
  • Combinations of above configurations

None of these configurations will prevent an API user from generating or accessing a payment request - they only affect the visibility of that payment request to web users via the FlipPay web interface.

Example scenarios

Scenario 1: default configurationAPI docs - FlipPay-2

  • No user groups are configured, no API custom templates are configured
  • All API templates are created via "customPR", no template ID is provided
  • All payment requests created via the Introducer platform and 3rd party system are available to all users via the web interface

Scenario 2: user groups configured

API docs - FlipPay-4

  • User groups "ABC" and "XYZ" are configured
    • Web user (1) is a member of "ABC"
    • Web user (2) is a member of "XYZ"
  • Request templates are configured
    • "Simple" template "RT-8888" is related to user group "XYZ"
    • "API Custom" template "RT-1234" is related to user group "ABC"
  • The Introducer platform uses "simplePR" to create payment requests, which are only accessible via the FlipPay web interface by web user (1), as this user is a member of user group "XYZ"
  • The 3rd party system uses "customPR" to create payment requests, which are only accessible via the FlipPay web interface by web user (2), as this user is a member of user group "ABC"

Scenario 3: user groups configured, API users allocated to groups

API docs - FlipPay-5

  • User groups "ABC" and "XYZ" are configured
    • Web user (1) is a member of "ABC"
    • Web user (2) is a member of "XYZ"
    • 3rd party system using an API user account, is a member of "XYZ"
    • Introducer is not a member of any group
  • Request templates are configured
    • "Simple" template "RT-8888" is related to user group "XYZ"
    • "API Custom" template "RT-1234" is related to user group "ABC"
  • The Introducer platform uses "simplePR" to create payment requests, which are only accessible via the FlipPay web interface by web user (1), as this user is a member of user group "XYZ"
  • The Introducer platform uses "customPR" to create payment requests without an "API Custom" template ID, which are no accessible via the FlipPay web interface by any web user
  • The 3rd party system uses "customPR" to create payment requests without an "API Custom" template ID, which are only accessible via the FlipPay web interface by web user (2), as this user and the API user are members of user group "XYZ"
  • The 3rd party system uses "customPR" to create payment requests with an "API Custom" template ID, which are accessible via the FlipPay web interface by web user (1), as this user is a member of user group "ABC"