Enterprise with Scheduler
Learn how to integrate your CRM with FlexPay’s Enterprise with Scheduler, automating transaction retries and enhancing recovery efficiency.
Introduction
The purpose of this document is to provide technical guidance for integrating with FlexPay's Enterprise with Scheduler feature. This integration enables you to send transaction details to FlexPay via individual API calls, after which FlexPay takes over the retry process by scheduling and triggering retry attempts. In this guide, you'll find information on the most common endpoints, the required API request formats, how to retrieve results, and use cases to help you validate your integration.
Requirements
To benefit from FlexPay’s Enterprise with Scheduler API integration, you will need the following:
- FlexPay Production account
- At least one Company configured in the account (There is a default company)
- Payment gateways configured for each Company
- FlexPay Retries configured for each Company
- Production API keys for each Company
Process Flow
- A subscription rebill is sent directly to the gateway. It declines.
- It is then rerouted & scheduled to send through FlexPay.
- 24 hours after the initial rebill failure, a Charge is sent to FlexPay
- FlexPay analyses the payload and determines whether to send the request to the gateway.
- FlexPay analyses the response from the gateway. If it’s a soft decline, a retry is scheduled for a future date. FlexPay continues this process until one of the following events takes place:
- The transaction approves.
- The transaction hard declines.
- A configuration limit is reached. Maximum 15 retries or 30 days, whichever is reached first.
- To determine the status of transactions in recovery, the system of record sends a request for the list of all transactions in a given time frame.
- To stop the recovery process, (for example, if a customer cancels their subscription) the system of record sends a Refund-Payment request to FlexPay.
Building your Integration
Before sending a transaction to FlexPay, a payment gateway must be configured under a Company. It must include the merchant account’s credentials so FlexPay can connect on your behalf. Depending on the complexity of your payment ecosystem, you could leverage the Gateway Management API. Learn more here.
Gateways can also be created manually in the FlexPay client portal. If you only have a small number of merchant accounts, this may be the easiest way to create the payment gateways in FlexPay. Learn more here.
The most common way of interacting with FlexPay's Enterprise API is through the Charge endpoint, this is how you provide details about a failed payment and kickstart the recovery process. FlexPay's AI-powered engine utilizes this information to recommend the optimal timing for retrying the failed payment. This not only enhances the chances of approval but also assists in preserving a healthy merchant account. Refund and VOID endpoints are also available to you. Let's explore these items in more detail:
Charge
API reference: Charge Request
As previously mentioned, your primary interaction with FlexPay will be through the charge endpoint. Once a rebill fails, the initial retry should be processed via FlexPay. When the FlexPay API receives a Charge request, the transaction is processed directly through the gateway. The response code, message, and details of any failed payment are analyzed, and a response is sent back to your CRM. This process only takes a few hundred milliseconds longer than a typical gateway transaction.
Once we receive the transaction, if we return a retry date, it is now in the FlexPay scheduler and will follow the recovery process. FlexPay will determine the next retry date and trigger any future transactions. If FlexPay has decided not to retry the transaction, we will return null in the retryDate field. You can look at FlexPay’s responseCode and message to determine the reason.
Note
Authorize and Capture are not supported for Enterprise with Scheduler.
Method: POST
URL: https://api.flexpay.io/v1/gateways/charge
Refer to our API reference document for detailed instructions on structuring the payload and understanding all the fields. While there are over 50 fields available, only a few are mandatory (7). Some fields are particularly important due to the insights our machine learning models can derive from them, while others may assist with improving the approval rate. The remaining fields are optional but may aid in reconciliation on your end. Below is a summary to help you prioritize the most critical fields.
Mandatory | Highly Recommended |
---|---|
merchantTransactionId | paymentMethod > expiryMonth |
orderId | paymentMethod > expiryYear |
amount | paymentMethod > firstSix |
currencyCode | paymentMethod > fullName |
retryCount | paymentMethod > address1 |
creditCardNumber OR gatewayPaymentMethodId | paymentMethod > postalCode |
paymentMethod > merchantAccountReferenceId OR gatewayToken | paymentMethod > city |
paymentMethod > state | |
paymentMethod > country | |
paymentMethod > email OR customerId | |
dateFirstAttempt | |
customerIp | |
mitStoredTransactionId |
Example Requests:
{
"transaction": {
"merchantTransactionId": "Trx-632541",
"orderId": "ORD-00094535",
"amount": 1100,
"currencyCode": "USD",
"retryCount": 1,
"customerId": "46209790217",
"paymentMethod": {
"creditCardNumber": "4111111111111111",
"lastFourDigits": "1111",
"firstSixDigits": "411111",
"expiryMonth": "05",
"expiryYear": "2025",
"fullName": "Carl Johson",
"address1": "560 Rue Peel",
"postalCode": "J7Y3U9",
"city": "Montreal",
"state": "QC",
"country": "CA",
"email": "[email protected]",
"merchantAccountReferenceId": "SUPPaysafeSandbox"
},
"dateFirstAttempt": "2024-09-12T19:20:30Z",
"customerIp": "10.10.10.10",
"mitStoredTransactionId": "6459276079792"
}
}
{
"transaction": {
"response": {
"avsCode": null,
"avsMessage": null,
"cvvCode": null,
"cvvMessage": null,
"errorCode": "3022",
"errorDetail": "The card has been declined due to insufficient funds."
},
"engagedRecoveryState": 0,
"paymentMethod": {
"paymentMethodId": "FFWYTQ6IUITU3FOOAGI6SCBFRM",
"creditCardNumber": "411111******1111",
"expiryMonth": "05",
"expiryYear": "2025",
"cvv": "",
"firstName": null,
"lastName": null,
"fullName": "Carl Johson",
"customerId": "46209790217",
"address1": "560 Rue Peel",
"address2": null,
"postalCode": "J7Y3U9",
"city": "Montreal",
"state": "QC",
"country": "CA",
"email": "[email protected]",
"phoneNumber": null,
"paymentMethodType": "CreditCard",
"fingerprint": null,
"lastFourDigits": "1111",
"firstSixDigits": "411111",
"cardType": "VISA",
"dateCreated": "2024-09-13T01:38:30.923Z",
"storageState": "Cached",
"merchantAccountReferenceId": "SUPPaysafeSandbox"
},
"transactionId": "068YJ2155M0000F1082C0DG0B39S4",
"transactionDate": "2024-09-13T01:38:30.829Z",
"transactionStatus": 2,
"message": "The card has been declined due to insufficient funds.",
"responseCode": "20023",
"transactionType": "Charge",
"merchantTransactionId": "Trx-632541",
"customerId": "46209790217",
"currencyCode": "USD",
"amount": 1100,
"gatewayToken": "ZFLC6BRZR7EUDA25AGIZJNXMUI",
"gatewayType": "paysafe",
"gatewayTransactionId": "452a5311-903b-418e-b036-9dc4d19f7007",
"merchantAccountReferenceId": "SUPPaysafeSandbox",
"assignedGatewayToken": "ZFLC6BRZR7EUDA25AGIZJNXMUI",
"orderId": "ORD-00094535",
"retryDate": "2024-09-14T22:00:00Z",
"retryCount": 1,
"dateFirstAttempt": "2024-09-12T19:20:30Z",
"description": null,
"productSku": null,
"subscriptionId": null,
"productCategory": null,
"billingPlan": null,
"customerIp": "10.10.10.10",
"billingCycle": 1,
"shippingAddress": {
"address1": null,
"address2": null,
"postalCode": null,
"city": null,
"state": null,
"country": null
},
"referenceData": "SAABAADTDfdf09wIyVYvBjmPyUGDXQGRlLbsosA2AFjTkuEBAAABkekIJS0=",
"disableCustomerRecovery": false,
"customVariable1": null,
"customVariable2": null,
"customVariable3": null,
"customVariable4": null,
"customVariable5": null
}
}
Note
You’re not just sending transaction data for FlexPay to process asynchronously. In most cases, we will process the transaction immediately and return a response with the result from your gateway. It's your choice whether to use this response or wait for the next LIST Transaction request.
The CRM must capture and process the response based on the responseCode.
Approved Transaction (Response Code: 10000): If the transaction is approved, the subscription should be reinstated to good standing.
Soft Decline (Response Code: 20000-29999): The payment is considered "In recovery" and FlexPay has scheduled a subsequent attempt.
Hard Decline (Response Code: 30000-49999): Continue with your established process for handling unrecovered payments.
API Error (Response Code: 50000-59999): Review the request you sent to FlexPay. A response in this range indicates an issue with your API request.
Get the status of transactions
Transaction List
API reference: List Request
To know the status of a transaction, you must send a GET request to receive a single transaction or a list of transactions that were processed in a specific time period. FlexPay recommends a daily request to receive details from the previous (or current) calendar day.
There are several parameters that can be configured when requesting a list of transactions.
Params | Description |
---|---|
order | The sorting order of the returned list. The default is asc, which returns the oldest records first. To list newer records first, use desc. |
sinceTransactionId | The transaction id of the item to start from (e.g., the last transaction id received in the previous list if iterating through records) By default, unbounded lists are returned in groups of 20 items. If there are more than 20 items in the list, use pagination to retrieve the next set of 20. To enforce determinism in a real-time system, pagination is indexed based on a specific record (as opposed to just a page number as is common in many web apps). To paginate to the next page, simply pass in the transactionId of the last record in the current result set. For instance, if the transactionId of the last transaction in the initial set of twenty transactions returned is JZE57KX6PMSU7MZLAFNIBQWJEQ, use that as the sinceTransactionId parameter to get the next set of 20 starting after that gateway. |
completedOnly | Request a list of transactions that have completed the recovery process. Note: If this parameter is not provided or null, response will return all transactions (Default/Current behavior). |
responseType | Request the simplified or detailed (Default) response. |
count | The number of transactions to return. By default, returns 20, maximum allowed is 100. |
startDate | Date range start of the returned list (Format: YYYY-MM-DD) |
endDate | Date range end of the returned list (Format: YYYY-MM-DD). To receive transactions from the current day, set this value to a future date (e.g. tomorrow). |
Note
FlexPay timestamps are all in UTC
Example:
Method: POST
{
"transactions": [
{
"transactionId": "068YFNQJ7W0000F108254NSBQYJA8",
"transactionDate": "2024-09-12T20:05:09.311Z",
"transactionStatus": 1,
"responseCode": "10000",
"message": "Approved.",
"transactionType": "Charge",
"retryDate": null,
"amount": 155,
"initialMerchantTransactionId": "Trx-60085",
"paymentMethodStorageState": "Cached",
"completionStatus": "RecoverySuccessful"
},
{
"transactionId": "068Y74J2W40000F10825MYY53Q2C8",
"transactionDate": "2024-09-12T00:11:39.105Z",
"transactionStatus": 1,
"responseCode": "10000",
"message": "Approved.",
"transactionType": "Charge",
"retryDate": null,
"amount": 155,
"initialMerchantTransactionId": "Trx-1673",
"paymentMethodStorageState": "Cached",
"completionStatus": "RecoverySuccessful"
},
{
"transactionId": "068Y74B26M0000F10823V3ERW5QZ0",
"transactionDate": "2024-09-12T00:10:41.589Z",
"transactionStatus": 2,
"responseCode": "20022",
"message": "Bank decline.",
"transactionType": "Charge",
"retryDate": "2024-09-13T21:00:00Z",
"amount": 155,
"initialMerchantTransactionId": "Trx-28298",
"paymentMethodStorageState": "Cached",
"completionStatus": "NotCompleted"
},
{
"transactionId": "068Y7473G80000F10829AAMNX9A8P",
"transactionDate": "2024-09-12T00:10:09.154Z",
"transactionStatus": 2,
"responseCode": "50115",
"message": "Invalid 'ShippingProvinceStateCode' length",
"transactionType": "Charge",
"retryDate": null,
"amount": 155,
"initialMerchantTransactionId": "Trx-49621",
"paymentMethodStorageState": "Cached",
"completionStatus": "RecoveryUnsuccessful"
}
]
}
{
"transactions": [
{
"acquirerAuthCode": "955851",
"gatewayTransactionId": "eb515031-f9df-4bdb-9ff2-3f300132bad4",
"gatewayPaymentMethodId": null,
"engagedRecoveryState": 0,
"currencyCode": "USD",
"retryDate": null,
"merchantTransactionId": "Trx-60085",
"merchantAccountReferenceId": "SUPPaysafeSandbox",
"initialTransactionId": "068YFNQJ7W0000F108254NSBQYJA8",
"customerId": "Cus-60085",
"orderId": "Order-60085",
"paymentMethodId": "HCGSCVP3PLGEHBAWAGI6PVXSXQ",
"paymentMethodStorageState": "Cached",
"paymentMethodType": "CreditCard",
"paymentMethodMerchantAccountReferenceId": null,
"errorCode": null,
"errorDetail": "",
"gateway": {
"token": "ZFLC6BRZR7EUDA25AGIZJNXMUI",
"gatewayType": "",
"name": "Support-Paysafe",
"referenceId": "SUPPaysafeSandbox"
},
"transactionId": "068YFNQJ7W0000F108254NSBQYJA8",
"transactionDate": "2024-09-12T20:05:09.311Z",
"transactionStatus": 1,
"responseCode": "10000",
"message": "Approved.",
"transactionType": "Charge",
"amount": 155,
"initialMerchantTransactionId": "Trx-60085",
"completionStatus": "RecoverySuccessful"
},
{
"acquirerAuthCode": "117558",
"gatewayTransactionId": "9540e043-144f-4c1f-90f5-91919749260d",
"gatewayPaymentMethodId": null,
"engagedRecoveryState": 0,
"currencyCode": "USD",
"retryDate": null,
"merchantTransactionId": "Trx-1673",
"merchantAccountReferenceId": "SUPPaysafeSandbox",
"initialTransactionId": "068Y74J2W40000F10825MYY53Q2C8",
"customerId": "Cus-1673",
"orderId": "Order-1673",
"paymentMethodId": "WT6U7GK5LL7ETGYPAGI6HESDF4",
"paymentMethodStorageState": "Cached",
"paymentMethodType": "CreditCard",
"paymentMethodMerchantAccountReferenceId": null,
"errorCode": null,
"errorDetail": "",
"gateway": {
"token": "ZFLC6BRZR7EUDA25AGIZJNXMUI",
"gatewayType": "",
"name": "Support-Paysafe",
"referenceId": "SUPPaysafeSandbox"
},
"transactionId": "068Y74J2W40000F10825MYY53Q2C8",
"transactionDate": "2024-09-12T00:11:39.105Z",
"transactionStatus": 1,
"responseCode": "10000",
"message": "Approved.",
"transactionType": "Charge",
"amount": 155,
"initialMerchantTransactionId": "Trx-1673",
"completionStatus": "RecoverySuccessful"
},
{
"acquirerAuthCode": null,
"gatewayTransactionId": "21bc7de9-a4de-48b9-8c28-3fa74805a7b3",
"gatewayPaymentMethodId": null,
"engagedRecoveryState": 0,
"currencyCode": "USD",
"retryDate": "2024-09-13T21:00:00Z",
"merchantTransactionId": "Trx-28298",
"merchantAccountReferenceId": "SUPPaysafeSandbox",
"initialTransactionId": "068Y74B26M0000F10823V3ERW5QZ0",
"customerId": "Cus-28298",
"orderId": "Order-28298",
"paymentMethodId": "KLV5JUT44NPEPBRJAGI6HELCQM",
"paymentMethodStorageState": "Cached",
"paymentMethodType": "CreditCard",
"paymentMethodMerchantAccountReferenceId": null,
"errorCode": "3061",
"errorDetail": "Invalid initial transaction reference",
"gateway": {
"token": "ZFLC6BRZR7EUDA25AGIZJNXMUI",
"gatewayType": "",
"name": "Support-Paysafe",
"referenceId": "SUPPaysafeSandbox"
},
"transactionId": "068Y74B26M0000F10823V3ERW5QZ0",
"transactionDate": "2024-09-12T00:10:41.589Z",
"transactionStatus": 2,
"responseCode": "20022",
"message": "Bank decline.",
"transactionType": "Charge",
"amount": 155,
"initialMerchantTransactionId": "Trx-28298",
"completionStatus": "NotCompleted"
},
{
"acquirerAuthCode": null,
"gatewayTransactionId": "fdf9f4eb-b772-4d8c-951b-4cb18729afd1",
"gatewayPaymentMethodId": null,
"engagedRecoveryState": 0,
"currencyCode": "USD",
"retryDate": null,
"merchantTransactionId": "Trx-49621",
"merchantAccountReferenceId": "SUPPaysafeSandbox",
"initialTransactionId": "068Y7473G80000F10829AAMNX9A8P",
"customerId": "Cus-49621",
"orderId": "Order-49621",
"paymentMethodId": "MAMGOGGGJHWUZN6EAGI6HEHEHY",
"paymentMethodStorageState": "Cached",
"paymentMethodType": "CreditCard",
"paymentMethodMerchantAccountReferenceId": null,
"errorCode": "5068",
"errorDetail": "Field Error(s)Field: card.cardExpiry.year must be greater than or equal to 1000",
"gateway": {
"token": "ZFLC6BRZR7EUDA25AGIZJNXMUI",
"gatewayType": "",
"name": "Support-Paysafe",
"referenceId": "SUPPaysafeSandbox"
},
"transactionId": "068Y7473G80000F10829AAMNX9A8P",
"transactionDate": "2024-09-12T00:10:09.154Z",
"transactionStatus": 2,
"responseCode": "50115",
"message": "Invalid 'ShippingProvinceStateCode' length",
"transactionType": "Charge",
"amount": 155,
"initialMerchantTransactionId": "Trx-49621",
"completionStatus": "RecoveryUnsuccessful"
}
]
}
Payment Status
API reference: Payment Status
The “payment-status” endpoint can be used to check the status of a transaction in recovery. It will return the last transaction processed for the payment in recovery.
Example:
Method: GET
{
"transactionId": "065MV5WGS800000200252K6PHRACW",
"transactionDate": "2023-10-20T14:57:40.554Z",
"transactionStatus": 1,
"completionStatus": "RecoverySuccessful",
"message": "Approved.",
"transactionType": "Charge",
"initialMerchantTransactionId": "802BA292-C385-4A84-BB49-6E58118CD1BE638334106606"
}
The completionStatus field is included in both the detailed and simplified response to provide clarity. This field describes the end-state of a payment. The list of possible values returned in this field are found in the Completion Status Value column below.
Transaction Type | Transaction Status | Completion Status |
---|---|---|
Charge | Approved | |
Refund | Approved | Refunded |
Charge | Declined | RecoveryUnsuccessful |
Refund | Declined | RecoveryCancelled |
Refund | Declined | RefundUnsuccessful |
Reconcile with your system
The transaction list and payment status requests will return certain fields that can help with reconciliation. FlexPay recommends using the initialMerchantTransactionId for this purpose. The value of this field was provided by your system when first sending a decline to FlexPay. This will remain consistent for every attempt processed by FlexPay.
Stop the retry process
There are two ways to stop the retry process via API:
- Use the Refund-Payment endpoint. This will stop recovery or refund the amount depending on the status of the payment.
- Using Redact (cancel) and Refund separately (alternative methods)
1. Refund-Payment Endpoint
API reference: Refund-Payment
The “refund-payment” endpoint will refund (if the transaction was approved) or cancel (if the transaction is still in recovery) with a single request.
- The refund-payment endpoint requires both merchantTransactionId (in the URL) and customerId (in the request body).
- The merchantTransactionId sent in the URL can be the initial value sent to Flexpay or any other merchantTransactionId’s from the chain of transactions.
- The customerId is required and must be sent in the request body.
- Refunds can only be processed for a Maximum of 4 months from the approval date.
- NOTE: The merchantTransactionId in the request body is not the same as the one sent in the URL. It is a unique values used to reconcile this specific request. It is not required, so the field can be empty (“”), null, or omitted.
Example:
Method: POST
URL: https://api.flexpay.io/v1/transactions/byMerchantTransactionId/trx-93745244108/refund-payment
{
"transaction": {
"merchantTransactionId": "order-123Avc2017-09-20T14:42:49.3003196+00:00",
"customerId": "customer-123",
"disableCustomerRecovery": true,
"amount": 0,
"customVariable1": "var1",
"customVariable2": "var2",
"customVariable3": "var3",
"customVariable4": "var4",
"customVariable5": "var5"
}
}
2.1 Redact Payment Method
API reference: Redact
When you send a Charge to FlexPay, we generate and return a value for the paymentMethodId in our response. This value needs to be stored and used in a new request to stop the retry process.
Using the PUT Redact Payment Method endpoint will remove a customer’s payment method from our system. This effectively blocks any further transactions done on this card. If it is attempted again, FlexPay will a 50134 Invalid payment method token response. This transaction will not be sent to the gateway.
2.2 Refund a transaction
API Reference: Refund
If a payment that was recovered by FlexPay is subsequently refunded, FlexPay will credit the merchant for any fees associated with the recovery. The simplest way to keep track of these refunds is to process them through FlexPay
Sandbox Testing
The FlexPay enablement team typically creates a 'Sandbox' account for testing, which mirrors the functionality of a production account. It’s important to exercise caution when configuring the account, as it can replicate real-world scenarios. The Sandbox environment allows you to test various use cases and payment scenarios.
The sandbox environment applies to Payment Gateways and API keys. Companies can have both Production and Sandbox API keys associated with them. When you create a Sandbox API Key, you will only be able to create & send requests to payment gateways in the Sandbox environment. Not all gateways are supported in the Sandbox. In the Sandbox Environment, there is a gateway called “FlexPay Sandbox”. This gateway must be used for the testing scenarios described below.
Refer to the Sandbox Guide for detailed instructions on how to complete your testing.
Requirements
The requirements for Sandbox testing are similar to those outlined previously in this guide, with two main differences. Instead of a regular FlexPay account, you need a FlexPay Test account, and instead of a regular payment gateway, you need a FlexPay Sandbox gateway. Please work closely with your integration manager to get these provisioned for you.
Use Cases
To simulate different scenarios and ensure your integration is ready for production, validate the following use cases by using the listed retryCount and Amounts.
Use Case 1: Testing Scheduling and Approval (using Credit Card)
- RetryCount = 0
- Amount = 9900
- creditCardNumber = Choose from our Testing Guide
- Flow:
- First transaction (sent by Integration Partner) will Decline and will automatically schedule a Retry (schedule command).
Retry will be executed automatically by the auto retry integration within 5-10 minutes. - Second transaction (sent by FlexPay Scheduler) will also Decline and will automatically schedule a Retry (schedule command)
- Third transaction (sent by FlexPay Scheduler) will Approve and there will be no more retries scheduled.
- First transaction (sent by Integration Partner) will Decline and will automatically schedule a Retry (schedule command).
Use Case 2: Testing Scheduling and Approval (using 3rd Party Token)
- RetryCount = 0
- Amout = 9900
- ThirdPartyToken = flexpay_auto_retries_sandbox_soft
- Example: "gatewayPaymentMethodId": "flexpay_auto_retries_sandbox_soft"
- Flow:
- First transaction (sent by Integration Partner) will Decline and will automatically schedule a Retry (schedule command).
- Retry will be executed automatically by the auto retry integration within 5-10 minutes.
Second transaction (sent by FlexPay Scheduler) will also Decline and will automatically schedule a Retry (schedule command) - Third transaction (sent by FlexPay Scheduler) will Approve and there will be no more retries scheduled.
Use Case 3: Testing Scheduling and Hard Decline (using Credit Card)
- RetryCount = 0
- Amount = 9910
- creditCardNumber = Choose from our Testing Guide
- Flow:
- First transaction (sent by Integration Partner) will Decline and will automatically schedule a Retry (schedule command).
- Retry will be executed automatically by the auto retry integration within 5-10 minutes.
Second transaction (sent by FlexPay Scheduler) will Hard Decline and there will be no more retries that will be scheduled.
Use Case 4: Testing Scheduling and Hard Decline (using 3rd Party Token)
- RetryCount = 0
- Amount = 9100
- ThirdPartyToken = flexpay_auto_retries_sandbox_hard
- Example: "gatewayPaymentMethodId": "flexpay_auto_retries_sandbox_hard"
- Flow:
- First transaction (sent by Integration Partner) will Decline and will automatically schedule a Retry (schedule command).
- Retry will be executed automatically by the auto retry integration within 5-10 minutes.
- Second transaction (sent by FlexPay Scheduler) will Hard Decline and there will be no more retries scheduled.
- First transaction (sent by Integration Partner) will Decline and will automatically schedule a Retry (schedule command).
Use Case 5: Testing a Cancel/Refund request for an Approval
- RetryCount =1
- Amount = 2008
- Payment Method:
- gatewayPaymentMethodId = cus_1234 or creditCardNumber = Choose from our Testing Guide
- Flow:
- Send a POST Charge request with the values listed above. This should return an approval
- Send a POST Refund-Payment request using the merchantTransactionId and customerId from the previous transaction
- The response should return an approved refund
- message: "Approved"
- responseCode: "10000"
Note
You can also test this scenario with any gateway supported in the sandbox environment. Simply use the values required by your gateway's sandbox to trigger an approval.
Use Case 6: Testing a Cancel/Refund request for a Soft Decline
- RetryCount =1
- Amount = 100
- Payment Method: creditCardNumber = Choose from our Testing Guide
- Flow:
- Send a POST Charge request with the values listed above. This should return a "Do Not Honor" soft decline.
- Send a POST Refund-Payment request using the merchantTransactionId and customerId from the previous transaction
- The response should return a hard decline
- message: "Original transaction has not been captured scheduled recovery has been cancelled."
- responseCode: "30103"
- This indicates that you have successfully cancelled FlexPay's recovery process for this payment.
- Flow:
Note
You can also test this scenario with any gateway supported in the sandbox environment. Simply use the values required by your gateway's sandbox to trigger a soft decline.
Use Case 7: Testing a GET Transaction List Request
- After sending transactions to FlexPay in the earlier use cases, send a GET Transaction List request.
- Use a date range in the parameters that covers the previous use cases.
Use Case 8: Testing GET Transaction List Pagination
- When using the GET transaction list endpoint, you may encounter queries that contain more than the maximum number of records (100). In this case, you'll need to use Pagination to retrieve the additional records.
- Follow this guide to test the Pagination feature
Use Case 9: Testing hard decline response
- RetryCount = 1
- Amount = 3016
- Payment Method:
- gatewayPaymentMethodId = cus_1234 or creditCardNumber = Choose from our Testing Guide
- Run this test if you are ingesting the result of the transaction response when first sending a decline to FlexPay.
- Use the correct values for the FlexPay Sandbox gateway, or your chosen gateway's Sandbox endpoint (if available), to send a hard decline request.
Use Case 10: Testing an API validation error
- Run this test if you are ingesting the result of the transaction response when first sending a decline to FlexPay.
- Trigger an API validation error by sending an invalid request to FlexPay's API. For example: send an empty string ("") or NULL value for "customerId" AND "email".
Updated 3 months ago