Introduction

The Enterprise or Enterprise with Scheduler integrations are both considered to be “Transaction” integrations. They will require your system to send transactions through FlexPay’s API to your underlying gateway.

Below you will find a list of potential stakeholders and scenarios that should be considered when defining the scope of and integration to FlexPay.

Stakeholder Impact

Below is a (non-exhaustive) list of the parts of your business that may be impacted by the addition of FlexPay to your Payment Authorization Management strategy. We’ve included examples of potential impact for each of these stakeholders.

Finance

• Invoicing and reconciliation. Is there any accounting processes or software that needs to be adapted to the Invisible Recovery™ process
• Monitoring of chargebacks. FlexPay clients do not see an increase in their chargeback rate. However, there may be an increase in the overall volume of chargebacks due to the increased recovery.

Business Intelligence

• Reporting on revenue and recovery performance. Make sure that performance calculations are based off a consistent data set and agreed-upon metrics.
• LTV analysis. A customer is recovered by FlexPay and then continues to rebill successfully outside of the FlexPay process, which is added to the ROI calculation of the recovery solution.
• Understand the potential lift provided by Invisible Recovery™.

Customer Support

• Possible changes to outbound communications when a new retry strategy is put in place.
• Ideally, any outbound communication is suspended when FlexPay is attempting recovery. This is the guiding principle behind Invisible Recovery™.
• Knowledge of customer subscription/invoice status to empower agents when dealing with inbound communication.

Marketing

• Communication of any process changes to existing clients.
• How to engage with customers (if necessary) once the recovery process is complete, whether successful or not.

Fulfillment

• Status changes and/or grace periods can affect fulfillment for those merchants dealing with physical goods.
• Digital products need to consider whether to continue providing access to the product or suspend service.

Legal

• Evaluate legal implications of the retry process.
• Understand regional differences for merchants serving multiple markets.
• Update policies, T&C’s, or any other customer facing documents, if required.
• Coordinate with IT team to ensure updates are in place with enough lead time to avoid blocking the release of an integration.

IT

• Properly define the scope of the integration, considering the stakeholders listed above.
• Work with internal stakeholders to properly define the business case to ensure prioritization.
• Consider how to do a soft launch (ramping of traffic) when defining the scope.
• Consider A/B testing the recovery process.
• Ensure the appropriate resources are allocated to complete the integration.

Integration Considerations:

Reconciliation

How do you reconcile transactions between systems. Determining the values that need to be sent and/or received in order to easily reconcile events.

FlexPay uses the concept of Payments and Transactions. A Payment is the amount you are trying to recover from your customer. Transactions are the attempts to recover that amount. We always think of recovery performance in terms of Payments.

Commissions

If you have a commission structure tied to your products, you will need to consider how this will be affected by the recovery process.

How will these be handled when a payment is in recovery and when it is approved? Do commissions require a specific timeframe for recovery?

Recovery Configuration

FlexPay’s Invisible Recovery works on a 30-day cycle. This means that no payment will be scheduled to retry past 30 days from the date that FlexPay first received the decline.

FlexPay will be able to retry a payment up to a maximum of 15 times, which is in line with VISA’s posted regulations. However, the purpose of FlexPay is to optimize the recovery process. As such, the average across all payments in Invisible Recovery is typically closer to 4 attempts.

The recovery window and maximum number of retry attempts can be limited if it is required for your business. FlexPay can also limit recovery to a calendar month.

Reporting

It is important to understand how FlexPay measures recovery performance. Our Reporting Guide can help understand how we calculate performance so you can generate similar reports internally.

What to send to FlexPay
Generally, merchants will have some kind of dunning and/or retry process in place. The most common scenario is that merchants will first send a rebill to their payment gateway. If it fails, then the next attempts will be sent through FlexPay.

📘

NOTE:

Sending all Recurring transactions through FlexPay is also a viable option. This would avoid any routing for Merchant Initiated Transactions and there would be no additional processing fees for passing through FlexPay.

Lifecycle of a Declined Payment

1. A customer is rebilled for their subscription, but the payment declines.
2. The next day, the payment is re-attempted by the merchant through FlexPay.
3. It declines again and FlexPay provides a retry date and time.
4. When the date and time arrives, the merchant sends the re-attempt through FlexPay (Or FlexPay triggers the attempt if using Scheduler).
5. FlexPay gets an approval and the customer’s subscription is in good standing.
6. In the next billing cycle, the customer is rebilled successfully through the normal process.

A few things to consider during this process:

• When a transaction is declined, you will need to determine what happens in your system to send it to FlexPay. If there is already a retry solution in place, can it be adapted to use FlexPay?
• Consider the structure of your rebill process and how the recovery lifecycle will fit into it. Do you have the concept of a Subscription > order/invoice > transaction? Each of these may have their own status depending on your process.
• Does a new status need to be created to accommodate the recovery process? Is a status change required at different levels of your process? (ex: Subscription status = “active”, Invoice status = “past due”).
• Retries not triggered by the FlexPay process. For example: a customer logs in and changes their payment method. Will this trigger and immediate retry attempt? How will these be handled in your system? If using Scheduler, you’ll need to notify FlexPay to stop retrying.
• If you have a digital product, will the customer still have access to it during the recovery process?

Successful recovery

How will a successful recovery affect your customer’s rebill cycle? Will you start billing them (weekly/monthly/yearly) based on the date of approval, or will you keep billing them on the original rebill date?

Failed Recovery

Hard Decline
Certain decline responses are considered Unrecoverable. FlexPay will not provide a retry date for these transactions. These customers can be flagged for further action based on your business needs. It is common to start outreach by customer support or simply have the subscription cancelled.

FlexPay Recovery Limits
When FlexPay has reached the limits of our recovery, we will return our own Hard Decline response, regardless of the underlying response coming from the payment gateway.

We suggest that these be treated as unrecoverable. However, some merchants will allow the next rebill cycle to continue and, if it declines again, send it back to FlexPay. It is important to note that there should be a limit placed on this process. You do not want your customers to have rebills creating failed payments indefinitely.

Error Handling

Communication Errors
In the event of an issue communicating with FlexPay, you may receive an unexpected HTTP response.

• A 400 response could be due to a communication error. If you didn’t receive a response payload from FlexPay, then you can re-send these transactions at a later time.
• A 403 response could mean that your request was blocked by our Web Application Firewall (WAF). In this case, you will need to reach out to the FlexPay integration and/or support team for guidance. The cause of this response is typically an issue with your request.

API Validation Error Handling
In the event of an API validation error in our response (response code in the 50K range), you’ll need to review the transaction(s) and determine what the issue is. Transactions that receive an API validation error will NOT be sent to the gateway and will not receive a retry date.

These should not be handled the same as a hard decline. Once the issue is fixed, they can be re-submitted to FlexPay. However, then must have a new (re: unique) merchant transaction id.