FPAY Carrier Billing API (Checkout)

What is fpay? #

fPay is Fonix’s direct billing solution, offering a quick and easy way to integrate mobile billing into your website.

How it works #

To use fPay you must have a registered merchant account with Fonix, if you are not an existing client please contact clientservices@fonix.com.

Once an account has been created you will be able to access the Fonix Dashboard at accounts.fonix.io. In the dashboard area of the platform, you can check stats, create new services, and amend existing services. When a service is live you can present users with the option to pay for products or services using carrier billing. When the user is ready to proceed to checkout we will require you to create a payment session through our APIs. Fonix will handle the payment processes on your behalf and notify you of any successful or failed transactions.

Payment flows (UK) #

Fonix provide a range of payment flows, the screens presented to an individual end user vary based on the service configuration and whether the end user is using a Mobile Data or WiFi Connection.

Wifi Flow (Pin Verification) #

When the user clicks the Continue button a free to end user SMS messageis triggered to the handset, containing a unique pin which is required for the second step of the authentication process. The user is then presented with the second Fonix screen, inviting them to enter the unique pin number previously sent to the handset. Once a valid pin is entered and verified by Fonix, a billing request is triggered to the Mobile Network Operator, and upon a successful confirmation from the Mobile Network Operator, is shown the success screen and a SMS receipt is sent to the user’s handset.

Mobile Data Flow(3G/4G/5G) #

This flow is only allowed for Single Purchases and for Subscription servicesthat are behind a secure login with a username and password.

The Three network does not allow this flow for any service types.

Hybrid flow #

The Hybrid flow is used as an alternative to the mobile data flow and the same conditions apply. This flow is only allowed on EE and Vodafone, with approval from the Mobile Network Operator.

WiFi Flow (Pin Verification) Default Message Wording #

Below is an overview of the current default SMS message wording for the WiFi Flow (Pin Verification) for all service types within fpay. Please note the message body is set as standard, but subject to change based on Mobile Network Operator or PSA guidance.

Single Payment Service

The first example shows the verification message sent to the handset containing the unique pin in order to confirm the user is in possession of the handset. The second message is the receipt message, confirming the purchase, this is triggered once the user has competed the pin verification on the payment screen.

Donation Service

The first example shows the verification message sent to the handset containing the unique pin in order to confirm the user is in possession of the handset. The second message is the receipt message, confirming the purchase, this is triggered once the user has competed the pin verification on the payment screen.

Subscription Service Without A Trial Period

The below example messages detail the free to consumer SMS messages a user will receive throughout the duration of a subscription service.
The first example shows the verification message sent to the handset containing the unique pin in order to confirm the user is in possession of the handset. The second message is the receipt message confirming the purchase, this is triggered once the user has completed the pin verification on the payment screen. This message also confirms the subscription has been started and provides details as to how the user can unsubscribe from the service. The third message is the receipt message for a successfully charged re-bill. This message will be sent out for every billing event for the duration of the subscription. The final message is the confirmation message sent to a user who has unsubscribed from the service.

Subscription Service With A Free Trial Period

The below example messages detail the free to consumer SMS messages a user will receive throughout the duration of a subscription service. The first example shows the verification message sent to the handset containing the unique pin in order to confirm the user is in possession of the handset. This message also details the length of the free trial period based on the service configuration.The second message is the receipt message confirming the purchase, this is triggered once the user has completed the pin verification on the payment screen. This message confirms the subscription has been startedand the end date of the free trial and details as to how the user can unsubscribe from the service. The third message is the receipt message for a successfully charged re-bill. This message will be sent out for every billing event for the duration of the subscription. The final message is the confirmation message sent to a user who has unsubscribed from the service.

Subscription Service With A Paid Trial Period

The below example messages detail the free to consumer SMS messages a user will receive throughout the duration of a subscription service.

The first example shows the verification message sent to the handset containing the unique pin in order to confirm the user is in possession of the handset. This message also details the length and cost of the paid trial period based on the service configuration.

The second message is the receipt message confirming the purchase, thisis triggered once the user has completed the pin verification on the payment screen. This message confirms the subscription has been startedand the end date of the paid trial and details as to how the user can unsubscribe from the service.

The third message is the receipt message for a successfully charged re-bill. This message will be sent out for every billing event for the duration of the subscription.

The final message is the confirmation message sent to a user who has unsubscribed from the service.

Security and connectivity #

Example API KEY:
 x-api-key:live_123456789abcdefg

On account creation and / or for each new service created, Fonix will provide you with a unique API Key that must be included in all API calls to fpay.fonix.io.
The API key must be added as an HTTP header to all API requests. The key:value pair for the header is X-API-KEY:your_api_key_here.

Creating a new service #

Before you start using the Fonix APIs, a valid service must be created and a number of parameters configured. A unique service id (often titled “sid”) is generated in the process in order to identify the relevant product or service.

Service fields #

Below is a list of required and optional fields available to use when creating a service. Some parameters can also be dynamically customised when you create a new payment session through our API. For more information about customisable fields please refer to the Create a payment session section of this documentation.

• *Service Name ()**: This is the name of your service within fPay. This will appear on the payment flow, reporting and the receipt SMS’s.
• *Service Type ()**: This field will determine the type of service that a user is going to go through. There are 5 types of services you can choose from: One-Off payment (for example top up credit or buy a service with a one-off transaction), Donation (same as one-off payment but specificly designed for donations), Subscriptions (Recurring billing every of a defined amount over a set billing frequency), Subscription with free trial and Subscription with paid trial (the trial period can be of different length and amount).
• *Merchant name ()**: This is the name of the merchant as it is displayed throughout the payment flow.
• *Customer care number()**: Your customer care number. It will be displayed to the end-users throughout the payment flow.
• API key: The API key used to identify you in the fPay APIs (subscription re-bills, create sessions, subscriptions stop, etc). This is automatically generated and it will be visible after your service has been approved.
• Promotional Text: This is extra wording to be displayed on top of the standard wording on the payment screens
• Amount: The amount to be charged. This has different behaviours depending on the type of your service. For Single payment and Donation services this is the amount charged for each transaction. For Subscription and Subscription donation this is the amount used for both the first transaction and all subsequent re-bills. For Subscription with free trial this is the amount used for re-bills (as the first transaction is free). For Subscription with paid trial this is the amount used for re-bills – the amount of the first transaction is the one set in the trial amount field.
• Billing frequency (* Subscription only): This is the billing frequency we will display to a user that comes to the payment screen. This will be displayed to the user throughout the payment flow. We don’t run re-bills automatically, you will have to make an API call to our re-bill endpoint at every billing frequency period. More information in the subscription section.
• Trial duration (* Subscription with paid or free trial only): This is the period of the trial (either free or paid). This will be shown to end-users throughout the payment flow and you can start re-bills for a subscription after its trial period expired.
• Trial amount (* Subscription with paid trial only): This is the amount charged for the trial period of a subscription (the first transaction that starts the subscription). The service amount is used for re-bills.
• Site URL: The URL for your main site. This will be used to whitelist your domain in case you want to embed the payment screen into your website. Format should be (https:// + domain only), e.g. https://example.com
• Success URL: This string is absolute URL that the end user will be redirected to upon a successful transaction.
• Failure URL: This string is absolute URL user will be redirected to when transaction fails or when user presses “Exit” on one of our screens
• Background notification URL: String representing absolute URL to which fpay will invoke a POST request to send notifications of the status of a transaction.
• *Unsubscribe URL ( subscription only)**: String representing absolute URL we will post stop subscription notifications if user texts STOP to a shortcode. Mandatory for Subscription type services
• STOP Shortcode: (optional, leave blank to use default 62442) This will replace the shortcode shown on the payment flow and receipt SMS’s. It must be provided by Fonix.
• GA Tracking ID: Goole Analytics tracking Id. Tracks clicks on Cancel/Exit button, Resend Token, landing and confirmation screen continue/confirm button clicks, success/retry buttons
• Upload image first screen: The image to display on the landing payment screen.
• Upload image second screen: The image displayed on the confirmation payment screen. If left blank we will use the first one for both.
• *Upload T&C ()**: A text file with the terms and conditions for the service to be linked to on the payment screen.

(*) Mandatory fields

After you create your service it will be in a Pending Approval state. Client Services will be contacted automatically to perform checks and final configurations. This is a manual process and may take 1 day (during normal UK working hours).

Configuration by Client Services #

There are some optional features that can be requested based on approval by the Fonix Client Services team

• Skip Success Page: Client services can configure a service to skip the success page in the payment flow and redirect the user straight to the ‘Success URL’ provided.
• Age verification: A service can be configured to only be accessiblefor users over 18 years
• Billing Amount Above £10: A service can be configured to chargeup to £10 without any approval required. If the service is configured to charge more than £10, Fonix need to seek approval from the Mobile Network Operators. A service cannot go live until permission is granted, please contact clientservices@fonix.com

Test and Live mode #

When a service is configured it will default to sandbox mode. Whilst in sandbox mode, any transactions made will simulate success and failures without actually billing the mobile handset. The payment flow will behave in exactly the same way as a live service, however, all SMS messages will include Sandbox Mode at the beginning to indicate it is a test service and that the handset will not be billed. Once all testing is completed, you can click on the Test/Live switch which will trigger a notification to Fonix to approve the service for the live environment.

Integration with fPay #

Integrating with fPay is easy, below you can find examples of the typical interaction between the end-user, your website and fPay. The following example are valid for all service types and payment flows.

In order to start using fpay, the configuration required involves:

• Creating a payment session through the API;
• Creating an endpoint to receive charge reports for each transaction and/or querying the status of the transaction;
• Being able to handle users redirected back to your website after a payment has been completed.

If the service is a subscription service, you need to:

• Notify us when a user unsubscribes from the service through your platform;
• Make an API call to re-bill existing subscriptions (trial ended and every billing frequency period, for example every month);
• Create an endpoint that is able to receive requests to unsubscribe an end-user. Fonix will send a notification to the configured url every time a user sends STOP to unsubscribe from the service or when we close stale subscriptions automatically.

For more information about subscription services please check the subscription section.

Charge reports #

You can create a payment session by sending a server-to-server request to the create payment session API. Fonix will process the request and return a redirect url in order to redirect the user to the payment flow. For each transaction created, you will receive a charge notification (or receipt) containing all the information related to the transaction and the status. When an end-user completes a purchase (either successfully or not) Fonix redirect the user back to you with the information regarding the status of the payment, enabling to you to identify the user and allow them access to the purchased content. For more information about the redirection process, please click here.

The charge notification is asynchronous, this means that in some cases the notification may arrive after the the end-user is redirected to your success/failure page or, in case of network issues, it may not reach you. This scenario is shown in the diagram below:

The charge notification is the primary method that should be utilised in order to obtain information regarding the status of a transaction. If for an reason the charge notification fails, you must still grant access to the content the user paid for. fPay provides secondary methods to access information about a specific transaction:

• Use the secret_success_token or secret_failure_token returned by the session creation API and cross-check it with thes_tokenreturned by the redirected user. This can provide an easy way to give access to users by checking if the s_token is equal to the secret_success_token.
• Query the transaction status API to retrieve the same information that would have been provided within the charge report.

Querying the status of a transaction. #

Some merchants would prefer to take an active approach and request the status of a transaction removing the requirement for the charge report notification. When a user returns to the website, you can request the status of the transaction utilising the transaction status API. If utilising this API you can ignore the charge report notification or alternatively do not configure a background notify URL for the service.

A payment session will still be initiated by sending a server-to-server request to the create payment session API, however, when the user is directed back to the website, either by user redirect or any other method, you can query fPay through the transaction status API and retrieve the transactional information associated to the user.

In the diagram above we show the call to the transaction status API being made synchronously to the request made by the end user to show your success page. Users may not be able to view the success page after a successful payment (they may lose internet connection or fail to click on the final continue button that redirects them back to you). In this scenario you should check the status of the transaction in an alternative way e.g when the user attempts to access the content.

Handling subscriptions #

Subscription services can be configured within the fpay platform to include an optional trial period. The trial period can be either free to the end user or a different offer amount to the fixed recurring billing amount.

In this section we are going to detail how subscription services work and the operations that can be performed.

Every subscription is triggered through the fPay payment screens. When auser initiates a subscription to the service, you need to create a payment session on fPay and redirect the user to Fonix.

This is an example of the lifespan of a typical subscription, with a trial period, and an explanation of the various date fields we pass back to you through different endpoints.

This is an example of the lifespan of a typical subscription without a trial period.

Please note, the first transaction is processed when the user completes the purchase through the Fonix payment screens. Subsquent subscription re-bills need to triggered by the merchant at each end_validity_date.

While the following is an example of the lifespan of a typical subscription without trial period.

Please notice that the first transaction is processed when the user goes through the payment page. you will only need to trigger re-bills at each end_validity_date.

Re-billing an active subscription #

The Fonix platform does not support automatic re-bills (or managed subscriptions) this needs to be handled by the merchant. The below rules need to be reviewed before implementing any re-billing logic:

• Rebills should be triggered between 8AM and 8PM of the target country;
• Rebills should be triggered on the same day of the subscription’s end date (the period of time for which the subscription is considered active);
• If the rebill fails, you can only trigger a rebill the day after the failed rebill;

Please refer to rebill subscription API for further integration details regarding this API.

Stopping a subscription #

There are 4 main ways a user can end a subscription:

• Users who are provided an option to unsubscribe from the service within an account environment or profile page. If the user unsubscribes from the service in this way, you need to trigger a call to the unsubscribe subscription endpoint. This will allow Fonix to handle users correctly should they attempt to re-subscribe to the service in the future;
• Through the customer care page in the reporting suite of fPay;
• The user sends a STOP message to the fpay stop shortcode;
• Automatic subscription expiry after 60 days at the end of validity of the subscription (subscription hasn’t been successfully rebilled for 60 days after the end of the validity period).

Every time a user is unsubscribed from our platform, using any of the methods described, you will receive a background notification from fPay notifying you of the successful operation. The user will also receive a SMS message to the subscribed handset notifying them of the successful operation.

Reactivating an existing subscription #

The below section details the scenario where a user has subscribed to a service, unsubscribes from the service and then wishes to re-join the service at a later date.
This can happen when the subscription is in 2 different states:

• Subscription is UNSUBSCRIBED and the end_validity_date is in the past.
• Subscription is UNSUBSCRIBED and the end_validity_date is in the future.

For the first case the subscription is after the validity period. This means the user should be redirected back to the Fonix payment screens as if they were a new user. The user will be required to go through the payment flow and a new subscription to the service will be created along with a new subscription ID.

For the second case the subscription is still within the validity period. In this scenario the user will still have to complete the payment process, however, the user will not be charged. Fonix will generate a successful status code (SUBSCRIPTION_REACTIVATED) and the existing subscription will re-enabled rather than creating a new subscription ID.

APIs #

The below section details the request and response information for the complete range of Fonix APIs.

Create a payment session #

This is the main entry point to create a payment session. When a user initiates a payment for either a one off transaction or a subscription service, you create a payment session using the below endpoint. If the transaction is successful, we return a redirect url which should be used to redirect the user to Fonix to complete the transaction process.

Target URL: https://fpay.fonix.io/rest/sessions/create?sid={service_id}&{other_params}={other_values}
Method: GET
Request values: url encoded

curl -v 'https://fpay.fonix.io/rest/sessions/create?sid=123456&mobile=47123456789&amount=300' --header 'X-API-KEY:live_1234abcdefg'

Response

{
    "code":0,
    "session":{
        "secret_failure_token":"b5cdab4f-6fc7-4fa7-8d38-b2c9d81eed3d",
        "secret_success_token":"2a0769c7-382b-4769-b1d1-757e2a196146",
        "payment_url":"http://fpay.co/newpayment.jsp?rsid=0459V2CHK0P6N6JTO8C32QCFY3TRWH0T6225",
        "redirectUrl":"newpayment.jsp?rsid=0459V2CHK0P6N6JTO8C32QCFY3TRWH0T6225",
        "guid":"be32c9c7-6647-43fa-a8ee-9c4371ea7f66"
    },
    "sessionId":"ZLYV2LAP6PGNEP2H5Y5FS21Z83CO735H",
    "message":"ok"
}

session

Transaction status #

The transaction status API allows you to retrieve the current status of the transaction.

Target URL: https://fpay.fonix.io/rest/v2/transactions/status/{transaction_id}
Method: GET
Request values:

curl -v 'https://fpay.fonix.io/rest/v2/transactions/status/123456-123456-123456-123456' --header 'X-API-KEY:live_1234abcdefg'

Response

{
    "subscription":{
        "billing_frequency":{
            "time_unit":"DAY",
            "time_amount":20
        },
        "end_validity_date":"2020-04-12 11:54:21.123",
        "id":1363635,
        "creation_date":"2020-03-23 11:53:21.007",
        "rebill_amount":{
            "amount":500,
            "currency":"GBP",
        },
        "start_date":"2020-03-23 11:53:21.123",
        "status":"SUBSCRIBED"
    },
    "transaction":{
        "user_ip":"78.33.71.182",
        "sandbox_mode":true,
        "status_code":"CHARGED",
        "service_id":150494,
        "track_user_flow":[
            {
                "tracking_action":"PAYMENT_LANDING_PAGE",
                "tracking_time":"2020-03-23 11:54:06.123"
            },
            {
                "tracking_action":"PAYMENT_CONFIRMATION_PAGE",
                "tracking_time":"2020-03-23 11:54:11.123"
            },
            {
                "tracking_action":"PROCESSING_BILLING_REQUEST",
                "tracking_time":"2020-03-23 11:54:21.123"
            },
            {
                "tracking_action":"PAYMENT_PROCESSING_PAGE",
                "tracking_time":"2020-03-23 11:54:21.123"
            },
            {
                "tracking_action":"PAYMENT_SUCCESS_PAGE.123",
                "tracking_time":"2020-03-23 11:54:23"
            },
            {
                "tracking_action":"PREPROCESSING_BILLING_REQUEST",
                "tracking_time":"2020-03-23 11:54:21.087"
            }
        ],
        "guid":"200e4cd9-3b16-4feb-bd0b-a69751f2a4c8",
        "creation_date":"2020-03-23 11:54:06.020",
        "charge_method":"direct",
        "msisdn":{
            "mobile_number":"447400000001",
            "moid":14319293,
            "operator":"o2-uk"
        },
        "merchant_params":{
            "tag":"product-1",
            "requestid":"xyz123",
            "x_my_request_id":"abcdef0123456789"
        },
        "flow":"3g",
        "billing":{
            "amount":500,
            "currency":"GBP"
        }
    },
    "status":"OK"
}

subscription json

transaction json

msisdn json

merchant params json

subscription status enum

billing frequency json

billing and rebill_amount

Stop subscription #

This API must be called when a user unsubscribes from the service. This will allow users to reactivate a subscription without being blocked.

Target URL: https://fpay.fonix.io/rest/subscriptions/{subscription_id}/stop
Method: POST
Request values:

curl -v 'https://fpay.fonix.io/rest/subscriptions/{subscription_id}/stop' --header 'x-api-key:xxxxxxxxxxxxx' --data ''

Response type: JSON

{
    "code":0,
    "sessionId":"MJA73J0VOSO05MR8JR2320H3KNI45OJH",
    "message":"ok"
}

Response

Re-bill subscription #

This endpoint is used to re-bill active subscriptions. Rules about re-billing a subscription can be found here; When you trigger a re-bill successfully, the response contains transactional information related to the newly created transaction. The status of this transaction will initially show as PENDING, whilst you wait for a callback receipt detailing the status of the transaction or you can query the status of the transaction using the transaction status API.

Target URL: https://fpay.fonix.io/rest/subscriptions/{subscription_id}
Method: POST
Request values:

curl -v 'https://fpay.fonix.io/rest/subscriptions/{subscription_id}' --header 'x-api-key:xxxxxxxxxxxxx' --data ''

Response

For successful transactions it’s likely that you will receive a pending transaction as result. You will receive a callback receipt when the transaction has been processed.

{
    "code":0,
    "sessionId":"63HDB7ZW760WX2B9XM4GGRP83DJRJ1TE",
    "message":"ok",
    "transaction":{
        "amount":100,
        "sandboxmode":true,
        "support_message":"",
        "monumber":"447429482354",
        "MerchantNotificationAttemptsCount":"1",
        "statustext":"Successful transaction",
        "statustime":"20200325171412",
        "CHARGEMETHOD":"direct",
        "moid":14000008,
        "statuscode":"CHARGED",
        "subscription_id":1,
        "MerchantNotificationStatus":"Exception - INVALID_SSL",
        "guid":"ccf0ce18-5c86-4d5e-91ba-db64793dda0f",
        "userResponse":"Successful transaction. Mobile number billed"
    }
}

transaction

Subscription status #

This API can be called at any time to retrieve the current status of a subscription.

Target URL: https://fpay.fonix.io/rest/subscriptions/status/{subscription_id}
Method: GET
Request values:

curl -v 'https://fpay.fonix.io/rest/subscriptions/status/1350512' --header 'x-api-key:xxxxxxxxxxxxx'

Response type: JSON

{
    "status":"OK",
    "subscription":
    {
        "id":1350512,
        "status":"INACTIVE",
        "start_date":"2019-10-10 08:12:55",
        "end_date":"2019-11-09 08:13:55",
        "amount":999,
        "currency":"GBP",
        "billing_frequency":"1.MONTH"
    }
}

Response

subscription

REFUND API #

Refund transaction #

The Fonix REFUND API allows merchants to refund a successful transaction made within the last 90 days.
If the refunded transaction is a subscription, the merchant can also expire the subscription by passing the expire-subscription parameter within the same request.

curl -X POST -i https://fpay.fonix.io/rest/transactions/{transaction-ext-id}/refund 
-H X-API-KEY:live_1234abcdefg  
-d expire-subscription=expire

Target URL: https://fpay.fonix.io/rest/transactions/{transaction-ext-id}/refund
Method: POST
Request Parameters:

Response

{
    "transaction_external_id":"123abc",
    "subscription_id":"123",
    "subscription_status":"UNSUBSCRIBED",
    "msisdn":"447400000000",
    "status_code":"OK",
    "message":"Successfully Refunded",
    "amount_refunded":"150"
}

Callbacks #

Callbacks are server-to-server requests that fPay sends you to notify you of changes related to your users that you may not be aware of.

Transaction notification #

The transaction notification or payment receipt is a server-to-server request that we make for every transaction you create through the create payment session API. You will only receive 1 notification per transaction unless we have problems reaching your servers. A notification to you is considered failed unless we receive a 2xx HTTP response code, any exceptions like timeouts or invalid ssl exceptions and any other response code will trigger a retry. Our retry policy is to attempt a notification every 10m for 24h for each transaction or until your server replies with a 200 code.

Target URL: Background notification url set in your service configuration or passed when creating the payment session. If both are set, the url passed when creating the payment session will be used
Method: POST
Values: Url encoded form

Stop subscription notification #

Stop notifications are server-to-server requests that fPay send every time a user is unsubscribed from the Fonix platform. This callback has the same retry policy as the transaction notification callback. If the request triggers an exception or the response is different from 200, we will retry the same request every 10 minutes for 24 hours. This callback is triggered by:

• Stop api that you can call when a user unsubscribes from your side;
• User sends STOP to shortcode to end the subscription;
• When the subscription hasn’t been successfully renewed in the last 60 days.

Target URL: Unsubscribe url set in your service configuration
Method: POST
Values: Url encoded form

Post-payment flow user redirection #

The last step you should be able to handle is when the end-user is redirected back to your website. After a successful or failed transaction we present a final screen and the end-user can click on the continue button to be redirected back to your website. When you start thinking about handling a redirected user you should keep in mind a few points:

• Not all users are redirected, so you can’t use this strategy to get accurate information about a transaction. Always use either the transaction notification callback or query the status of the transaction to securely retrieve payment information;
• Data goes through the end-user’s browser, this means that any parameter we pass during the redirect could potentially be changed by an attacker. This means that you shouldn’t rely only on these information – you should either wait for a transaction notification callback or query the status of the transaction;
• In case of network problems (i.e. timeouts, invalid ssl certificate, connection dropped, delays, etc) you may receive the transaction notification callback at any point after the user has been redirected back to you; To avoid this you can adopt a hybrid solution where you use the query transaction status API if you didn’t receive a notification yet when a user is redirected or tries to access the content or use the query transaction status API only or keep waiting for the background notification, but you can give advanced access to the user by comparing the s_token parameter passed by the redirected user with the secret_success_token.

In your service configuration or when you create a payment session you can specify 2 different URLs: success and failure. The user will be redirected to your success url for the following transaction status codes: CHARGED, ALREADY_SUBSCRIBED and SUBSCRIPTION_REACTIVATED and to the failure url for any other status code or when the end-user clicks on the Cancel button.
Below a table of all the parameters that you will receive when the user is redirected back to you through the success url:

Below a table of all the parameters that you will receive when the user is redirected back to you through the failure url:

Codes #

Error codes #

The following is a list of all the errors that we could display in the badconfig error page.

The following is a list of all the errors you could get as response to API calls.

Status codes #

Operator aliases #

Integration checklist #

Single payment and Donation #

• Initiate a payment session;
• Handle transaction notification callback;
• Handle redirected user after a successful or failed transaction.

Subscription #

• Initiate a payment session;
• Handle transaction notification callback;
• Handle redirected user after a successful or failed transaction;

For successfull payment flows only:

• Trigger re-bills at every billing frequency;
• Handle stop subscription notification callback;
• Notify us of any subscription you close on your side.

Subscription with paid or free trial #

• Initiate a payment session;
• Handle transaction notification callback;
• Handle redirected user after a successful or failed transaction;

For successfull payment flows only:

• Trigger the first re-bill at the end of the trial period;
• Trigger re-bills at every billing frequency;
• Handle stop subscription notification callback;
• Notify us of any subscription you close on your side.