Payment requests

Using a Merchant account, a Merchant can send requests for payment to Customers who then can pay for products/services via the available options. FlipPay extends this process to allow a Merchant to configure payment options, branding, workflow and data collection/display throughout the payment experience.

At the core of the experience is the payment request - this object is a container for configuration options, customer and individual transactions enacted to complete the payment request.

Payment requests are created on a Merchant account via the web interface or API:

• Via web interface, authorised users send payment requests to Customers, using pre-configured templates containing their preferred settings
• Via API, authorised users can create payment requests by referencing an existing template, or by providing all of the fields and settings required for an entirely unique payment request

Payment requests can be configured to enable “pay now” and “pay later” options:

• When a Customer selects “pay now”, the amount is paid directly to the Merchant (ignoring fees for this discussion)
• “Pay now” can be configured as a one-off payment, or a recurring schedule of payments (similar to a subscription) - either way, a “pay now” payment represents an immediate debit of the Customer’s payment method and a credit to the Merchant’s nominated bank account
• When a Customer selects “pay later”, the Customer accepts a contractual agreement with FlipPay whereby FlipPay will credit the Merchant the requested amount on behalf of the Customer, and debit the Customer’s payment method over time to repay the initial outlay

Payment requests can also be configured with a range of other options to create a white-label experience per Merchant preference.

Once created, payment requests are sent to Customers as a unique encrypted URL. Following this URL displays a payment page to the Customer, rendered per the settings configured in the Merchant account and the individual payment request. Customers then select from configured payment options and complete the payment transaction within the payment page.

Payment requests can proceed through different lifecycles depending on the payment options configured (pay later, pay now one-off, pay now recurring). 

Pay later

The model below shows the lifecycle and statuses of a payment request where a "pay-later" option is selected. The model assumes the payment request is created with a single payment option - in the scenario where a payment request is created with pay-now and pay-later options, the status model will flow according to the payment option selected by the Customer.

Note:

• If the product enabled on the payment request contains a required product field of “file-upload” type, the payment request is created in the “info-required” status and remains so until a valid file is loaded to the product field (the payment request will move to a “pending” status once the file is present)
• Otherwise, payment requests are always created in the “pending” status, and will remain so until they expire (“expired), or are accepted (“active”) by a Customer, or cancelled by a Merchant (“cancelled”)
• If the payment request expires, it can be resent (“resent”), and will present in this new status until it again expires, or is accepted by a Customer, or cancelled by a Merchant
• When a pay later plan is accepted by a Customer, the payment request will present as “active” - importantly, this is also the status that confirms FlipPay will have disbursed funds to the Merchant
• A payment request remains in “active” status until it is paid out, at which point it will present as “complete”
• Some products enable an option for Customers to request an extension to their due date, if this is the case and is approved for a payment request, the status will show as “extended” and remain so until it is paid out

Pay now (one-off)

The model below shows the lifecycle and statuses of a payment request where a "pay-now (one-off)" option is selected. The model assumes the payment request is created with a single payment option - in the scenario where a payment request is created with pay-now and pay-later options, the status model will flow according to the payment option selected by the Customer.

Note:

• Pay-now options require no product fields, so the payment request will begin in “pending” and remain so until it expires (“expired) and is resent ("resent") or is cancelled by a Merchant (“cancelled”), or a successful payment is processed by a Customer (“complete”)
• The payment request will remain in “pending” if the Customer’s card is declined (allowing the Customer to retry)

Pay-now (recurring)

The model below shows the lifecycle and statuses of a payment request where a "pay-now (recurring)" option is selected. 

Note:

• Pay-now (recurring) works similarly to pay-now (one-off) in terms of “pending”, “expired” and “resent” statuses
• A pay-now (recurring) enabled payment request will show as “active” when the Customer accepts the recurring schedule, and while the schedule is current (i.e. between the start date and end date)
• When the schedule completes, the payment request will show as “complete”
• A recurring payment request can also be cancelled by the Merchant at any time, allowing it to move to the “cancelled” status as indicated