The buyer approves the subscription terms, and the seller accepts the initial payment before granting access. InFlow records the subscription and manages later billing. Your application still decides what the subscription includes, such as the reports a subscriber can read.

Later requests use the existing subscription. The buyer gets a fresh credential for the seller’s current challenge and submits it to the endpoint. The seller checks that credential through InFlow before returning the report. A request within an already-paid period does not incur another subscription charge.

The recurring price is fixed by the subscription terms. Counting requests and billing their measured usage is not part of this flow. Application quotas, access permissions, and report delivery remain your application’s responsibility.

A Python or Rust buyer can subscribe to a Go or Node.js seller. The buyer and seller do not need to use the same language.

Sellers need an InFlow Seller account, its API key, and a private challenge-signing secret. Buyers need an authenticated InFlow account funded in the subscription currency. Keep both sides in the same environment; start in Sandbox. See Accounts and environments and InFlow balance for setup.

Describe the access being sold and set its recurring terms. For the report service, the offer is 9.99 USDC every month. The subscription also has an end date, after which access and renewals stop.

InFlow records the billing schedule when the purchase starts. Read the subscription’s next billing date rather than calculating it from your application’s first successful report response. The examples use a fixed end date; choose and maintain an appropriate future date for your own offer.

These seller fragments extend Accept MPP. Keep its account setup, application authorization, input checks, and error handling. The same endpoint handles initial purchase and later subscription access.

plan := "reports-monthly"
offer := seller.Offer{
    Subscription: &mpp.SubscriptionRequest{
        ChargeRequest: mpp.ChargeRequest{
            Amount: "9.99", Currency: "USDC",
        },
        PeriodUnit:          "month",
        PeriodCount:         1,
        SubscriptionExpires: "2027-12-31T23:59:59Z",
        ExternalID:          &plan,
    },
}

import {
  Mppx, inflow, inflowSubscriptions, paymentHttpTransport,
} from '@inflowpayai/mpp-seller';

export function createReportsHandler(apiKey: string, secretKey: string) {
  const payments = Mppx.create({
    methods: [inflow.subscription({ apiKey, environment: 'sandbox' })],
    secretKey,
    transport: paymentHttpTransport(),
  });
  const subscribe = inflowSubscriptions(payments, [{
    amount: '9.99', currency: 'USDC',
    periodUnit: 'month', periodCount: 1,
    subscriptionExpires: '2027-12-31T23:59:59Z',
    externalId: 'reports-monthly',
  }]);

  return async (request: Request): Promise<Response> => {
    const result = await subscribe(request);
    if (result.status === 402) return result.challenge;
    return result.withReceipt(Response.json(
      { report: 'Your subscriber report is ready.' },
      { headers: { 'Cache-Control': 'no-store' } },
    ));
  };
}

Existing subscriptions keep their agreed terms. Changing the endpoint’s price, currency, billing interval, or seller reference can prevent those subscribers from using the new offer. Keep an offer matching existing subscriptions while introducing a separately identified plan. Do not silently purchase a replacement when the old subscription no longer matches.

• First purchase. Select the seller’s subscription offer and check its recurring price, period, and end date. Start the purchase without an existing subscription ID. Follow the required approval flow, then submit the resulting payment credential to the seller.
• Successful activation. The seller settles the initial payment and returns the report with a Payment-Receipt. Retain its subscriptionId with the buyer, seller, environment, and plan in your application. A prepared credential alone does not prove activation or delivery.
• Later access. Request the report again and supply the saved subscription ID to the buyer SDK. The SDK asks InFlow for a fresh credential tied to the current challenge. Submit that credential to the same seller and check the response and receipt.

The subscription ID identifies the agreement; it is not an access token. InFlow checks the authenticated buyer and the offer’s terms before issuing an access credential. Keep credentials private and do not reuse one as a permanent subscription token.

The fragments below adapt the buyer functions in Pay with MPP for later access. Use a known subscription endpoint and the saved ID. Retain that guide’s timeouts, response checks, receipt parsing, and cleanup. These are changes to that flow, not standalone applications.

response, err := client.Do(request, buyer.PaymentOptions{
    SubscriptionID: subscriptionID,
})

const method = inflow.subscription({
  apiKey, environment: 'sandbox', timeoutMs: 900_000,
});
const payments = Mppx.create({
  methods: [method], polyfill: false, maxPaymentRetries: 1,
});

const response = await payments.fetch(url, {
  context: { subscriptionId },
  redirect: 'error', signal: controller.signal,
});

BuyerMethod(
    ClientOptions(environment="sandbox", api_key=api_key),
    intent="subscription",
    subscription_id=subscription_id,
)

let challenge = challenges.iter().find(|challenge| {
    challenge.method.as_str() == "inflow"
        && challenge.intent.as_str() == "subscription"
}).ok_or("No InFlow subscription offer; no purchase was started")?;
drop(response);
let cancellation = CancellationToken::new();
let payment = buyer.prepare(challenge, PaymentOptions {
    subscription_id: Some(subscription_id.to_owned()),
    ..Default::default()
}, &cancellation).await?;

Supplying no subscription ID requests a new purchase. If the original payment succeeded but your application lost the receipt, recover that subscription before buying again. Buyers can inspect their Sandbox subscriptions or production subscriptions.

Applications can list owned subscriptions with GET /v1/subscriptions and inspect one with GET /v1/subscriptions/{subscriptionId}. Use your InFlow credentials against the matching API environment, not the seller’s report endpoint. The API reference describes these operations and their responses.

InFlow schedules recurring charges against the buyer’s balance. Your seller application does not need its own billing timer. Accessing the resource can also trigger settlement when the current billing period has not been paid.

If renewal fails because the balance is insufficient, the subscription becomes past due and InFlow schedules further attempts. Access requiring that unpaid period is denied unless settlement succeeds. A past-due status is not a promise of free access during retries.

Tell the buyer to fund the subscription currency in the same InFlow environment. Check the subscription’s status and next billing date before retrying access. Keep using the existing subscription ID; omitting it would request another purchase. InFlow can mark the subscription failed when its renewal retry window ends.

Preserve the existing payment details when a response is interrupted. Do not treat every error as a reason to subscribe again. Status and recovery explains how to separate an uncertain payment from a confirmed failure.

Buyers can cancel a subscription from its InFlow dashboard details. Sellers can revoke a subscription belonging to them. For application-driven cancellation, use the subscription ID with this InFlow API endpoint:

DELETE /v1/subscriptions/{subscriptionId}/delete

Authenticate as the buyer or seller against the matching API environment. The caller’s role determines cancellation or revocation; a successful call returns HTTP 200.

Cancellation and revocation stop further billing and immediately prevent subscription access. They do not wait for the paid period to end, and they do not refund earlier payments. Explain this behavior to buyers before offering a cancellation control.

Reaching subscriptionExpires also ends access and renewals. Removing a plan from your seller endpoint is not a substitute for cancelling the existing subscriptions; those agreements remain recorded in InFlow.

Cancelling a pending payment approval is different from cancelling an active subscription. Buyer SDK cleanup and approval-cancellation helpers do not end a subscription. Use the subscription dashboard or cancellation endpoint for that operation.

Use controlled Sandbox buyer and seller accounts. For renewal testing, periodUnit: 'minute' with periodCount: 5 provides a short billing interval. Keep this testing plan separate from the customer-facing monthly offer, and cancel it when finished.

• Complete the first purchase. Confirm the report, receipt subscription ID, active subscription, and initial transaction in InFlow.
• Request another report within the paid period with the saved subscription ID. Confirm access without a second purchase or another subscription charge.
• Reject the initial approval. Confirm that the seller does not deliver the report and the application does not start another purchase automatically.
• Allow the next billing period to arrive. Confirm the renewal transaction and access with the same subscription ID.
• Test an insufficient balance at renewal. Confirm the failed access, past-due status, and recovery after funding within the retry window.
• Try another buyer’s subscription ID or a plan with different terms. Confirm rejection without delivering the report or creating a replacement subscription.
• Cancel, revoke, and expire separate test subscriptions. Confirm that later requests cannot access the resource through those subscriptions.
• Interrupt delivery after the initial payment. Confirm that recovery finds the existing subscription instead of creating a duplicate.

Keep these running-system checks alongside your project’s unit tests, integration tests, and coverage requirements. A simulated challenge alone does not prove recurring billing, subscription access, or cancellation works end to end.