Skip to main content
FastFlowPe sends subscription callbacks as HTTP POST requests to the merchant’s configured subscription_callback_url. There are currently two merchant-facing subscription callback event types:
  • SUBSCRIPTION
  • SUBSCRIPTION_TRANSACTION
Quick ReferenceDelivery Method: HTTP POSTDestination: Merchant configured subscription_callback_urlEvent Types: SUBSCRIPTION, SUBSCRIPTION_TRANSACTIONSuccessful Delivery: Any HTTP 2xx responseMaximum Delivery Attempts: 3 total attempts for the same event

SUBSCRIPTION Event

The SUBSCRIPTION event is sent when the subscription lifecycle or mandate authorization status changes. This includes events such as:
  • Mandate approval
  • Mandate failure
  • Subscription pause
  • Subscription activation
  • Subscription cancellation
  • Subscription completion
  • Mandate expiry
  • Mandate revocation
  • Subscription status changes detected during polling
Initial subscription creation by itself does not currently trigger this callback.

Callback Example

Subscription Object

string
Callback event type.For subscription lifecycle callbacks, this is SUBSCRIPTION.
string
Internal FastFlowPe subscription ID.
string
Payment mode used for the subscription.
integer
Maximum number of billing cycles configured for the subscription.
integer
Number of successfully completed billing cycles.
integer
Number of interval units between recurring charges.
string
Interval type configured for the plan.
string
Amount configured for each subscription billing cycle.
string
Amount used for mandate authorization.
string
Subscription plan start timestamp.
string
Subscription plan expiry timestamp.
string
Next scheduled billing timestamp.
string
Merchant-defined subscription reference ID.
string
Current lifecycle status of the subscription.
string
Current mandate authorization status.

Subscription Status Values

Authorization Status Values

Payment Mode Values

Plan Interval Values


SUBSCRIPTION_TRANSACTION Event

The SUBSCRIPTION_TRANSACTION event is sent for an individual subscription payment or mandate authorization transaction. The callback contains the subscription object together with a transaction object.

Callback Example

Select the SUBSCRIPTION_TRANSACTION tab in the response example panel to view the full transaction callback payload.

Transaction Object

string
Unique FastFlowPe transaction ID for the subscription transaction.
string
Transaction amount.
string
Payment mode used for the transaction.Example: UPI_RECURRING
string
UTR or payment reference returned for the transaction.This field may be null.
string
Current status of the subscription transaction.
object
Customer information associated with the transaction.This field may be null.
string
Human-readable payment response message.This field may be null.
string
Billing period associated with the subscription transaction.
integer
Attempt number for the transaction within the billing cycle.
integer
Billing cycle number associated with the transaction.
string
Failure code associated with the transaction.This field may be null.
string
Identifies the purpose of the transaction.This field may be null.

Transaction Status Values

Normal terminal callback statuses are SUCCESS and FAILED.PSP CANCELLED payment statuses are normalized to FAILED.

Transaction Remarks

Nullable Transaction Fields

The following transaction fields may be null:
  • utr
  • resp_message
  • failure_code
  • remark
  • transaction_details
transaction_details contains the transaction’s customer information.Depending on the payment mode, it may contain sensitive payment or banking information. Merchants should store and process callback payloads securely.

Callback Headers

Subscription callbacks include:

Delivery and Retries

FastFlowPe expects the merchant callback endpoint to return an HTTP 2xx status code to consider the callback successfully delivered. If the callback does not receive a 2xx response, FastFlowPe retries delivery for the same event.
FastFlowPe makes a maximum of 3 delivery attempts for the same callback event.This means the initial callback plus up to 2 retry attempts.If the merchant endpoint returns an HTTP 2xx response on any attempt, the callback is considered successfully delivered and no further retries are made.
Merchant callback handlers should be idempotent because the same event may be delivered more than once when retries occur.

Callback Deduplication

SUBSCRIPTION_TRANSACTION

SUBSCRIPTION_TRANSACTION callbacks are deduplicated using:
  • Transaction ID
  • Transaction status
This prevents the same transaction status from being repeatedly delivered for the same transaction.

SUBSCRIPTION

SUBSCRIPTION lifecycle callbacks are append-only. Because of this, the same subscription status may be delivered more than once.
Do not assume that callback events will be delivered exactly once.Your callback endpoint should safely handle repeated delivery of the same event.
When receiving a subscription callback:
  1. Accept the HTTP POST request.
  2. Read event_type.
  3. Handle SUBSCRIPTION and SUBSCRIPTION_TRANSACTION separately.
  4. Process the callback idempotently.
  5. Return an HTTP 2xx response after successfully accepting and processing the event.
Return an HTTP 2xx response as soon as the callback has been successfully accepted.If FastFlowPe does not receive a 2xx response, the same event may be retried up to the maximum of 3 total delivery attempts.
Use the internal FastFlowPe subscription ID from subscription.id to correlate callbacks with subscriptions in your system.For transaction callbacks, use transaction.id as the unique transaction identifier.