What changes in your billing code when you are not the seller
Most of a subscription integration is the same under a Merchant of Record: plans, trials, upgrades, dunning, entitlements. A handful of things are genuinely different, and those are the ones that cause incidents — where the invoice comes from, what a refund does to access, and the fact that tax is decided on every renewal rather than fixed at signup.
The billing surface you do not have to build
- Trials and their conversion
- Start a plan in trial and let it roll into a paid subscription on its own, or end the trial early through the API when someone upgrades before it runs out.
- Plan changes, prorated and previewable
- Upgrades and downgrades are worked out to the day. The API returns what the next renewal will cost before you commit the change, which is what lets an in-app upgrade screen quote a real number.
- Dunning on failed renewals
- Cards expire and banks decline. Failed charges are retried on a schedule and the customer is told, rather than a subscription being dropped on the first decline.
- Pause instead of cancel
- Collection can be paused and resumed on a date you choose. It is a save your cancellation flow can offer when the alternative on screen is a cancel button.
- Usage and mid-cycle charges
- Pay-as-you-go pricing for metered products, and one-off amounts charged onto a live subscription for an overage, an add-on or seats bought halfway through the month.
- A portal on your own domain
- Plan changes, card updates, invoices, order history and cancellation, under your branding, with magic-link sign-in instead of another password for your users to lose.
Implementing it in the order that avoids rework
- 01
Model pricing as products, offers and plans
A product is the thing you sell; an offer is a purchasable pricing configuration of it. One subscription product carries monthly, annual and any custom interval, which is much easier to reason about later than three near-duplicate products.
- 02
Carry your own user id through the checkout
Custom fields exist to identify the buyer in your system, and the email can be pre-filled from the URL. Wire this before you write any entitlement code — retrofitting the mapping means reconciling live subscribers by email address.
- 03
Grant on the event, revoke on the event
Open access on payment_success, which fires for the first charge and every renewal. Do not fulfil on the browser redirect, and do not fulfil on subscription_created alone: it can arrive while the first payment is still pending.
- 04
Run the whole lifecycle in sandbox first
Trial, first charge, upgrade, failed renewal, refund, cancellation. Every one of those is a webhook your application has to survive, and sandbox mode runs all of them without a real card.
The four things that are different under an MoR
Tax is a per-renewal decision, not a signup one
A subscription signed in one tax year keeps charging into the next, and rates and rules move underneath it. Each renewal is priced against current rates for the buyer's country and filed under our registrations, so an old subscription cannot quietly turn into a liability.
Refunds and disputes reach you as events
The dispute is against us, because we are the seller. Your application learns the outcome from the payment refunded event rather than from a decision one of your staff made, so entitlement revocation has to be driven by the event stream or you will have customers still using a product they were refunded for.
Billing details at checkout are not optional
The buyer's country and billing information are required because we are the legal seller and the tax has to be right. That is one more step than a bare card form, and it is the trade for a valid invoice and a correct rate.
Procurement will ask who the supplier is
The answer is Fungies Inc., not you. Business customers who enter a tax ID at checkout receive a proper invoice by email for each renewal. Worth knowing before a finance team asks, rather than during a renewal negotiation.
What sellers say once they have switched
★★★★★ 4.8/5 from 10 reviews on G2 →
Vadim Finayev “We work with quite a few merchants of record, but none comes close to the support and speed of implementation of Fungies. If you want a payment partner that actually gives you the feeling they want to work with you — rather than leaving you on read for three days or randomly restricting your account — you are in the right place.”
David Elliott “I researched the options and Fungies was the best fit for functionality and customisation within a store builder you can connect to your own domain. Taking a small percentage of sales, instead of charging a subscription for every environment and plugin, is refreshing.”
Elnura Abdimanap Kyzy “The platform is user-friendly, integrates easily with APIs and webhooks, and simplifies managing digital products and subscriptions. We were up and running quickly and support has been responsive throughout. Fungies is clearly tailored to the needs of SaaS businesses.”
Francisco Magnone Rienzi “Fungies has been a great partner — fast setup, competitive pricing, and real humans providing quick answers. They are constantly rolling out new features, and I am excited to see what is next.”
Questions from teams mid-integration
What the model is, who it suits, and how it compares.
Build the product, not the billing system
Model one plan, carry a user id through a sandbox checkout, and run a trial through to a renewal before a real card is ever charged.