Skip to content
EdgeKit

Subscriptions

EdgeKit Subscriptions covers what your organization sells and what a purchase gives the user. You describe the access in a catalog. Your page sells it through checkout. EdgeKit then writes a grant: the stored fact that a user has access. Your billing provider holds the money, and EdgeKit reads its records back to keep each grant in step with it.

The catalog, the grants and the copy of your billing records all live in your organization’s own database. No other organization shares it.

The catalog

Section titled “The catalog”

The catalog has three kinds of record:

  • Product: an access set, meaning what a grant lets someone read or do. A product names the sites it covers, an optional condition over content facts, and the capabilities it confers. It has no price. What other platforms call a plan is split in two here: the access is the product, and the way it is sold is the offer.
  • Offer: one way to sell one product. An offer has a name, a code, a trial, an optional introductory discount and the prices your billing provider charges. One product usually has several offers, for example monthly and annual. A new offer is not for sale until you mark it Purchasable.
  • Capability: a right that is not content access, such as job posts or event tickets. It can have a quota unit. EdgeKit enforces one quota, seats. Your own application enforces every other quota.

Catalog records are part of your draft. A change reaches checkout and decisions only after you deploy it, except a product’s sites, slug and rank and an offer’s audience, which decisions read as saved. See Versions.

Grants

Section titled “Grants”

A grant gives one subject access to one product. The subject is exactly one of a user or a user organization (see User organizations). A grant has a start, an expiry and a status, active, suspended or revoked, and carries no price, currency or billing interval. The states and the Grants screen are described in Grants.

Today one thing writes a grant: a purchase through checkout. Checkout finds or creates the user from the email address the buyer typed, then charges the card, then writes the grant. A grant never waits for a user to exist, so there is no pending grant and no grant without a user.

Your billing provider

Section titled “Your billing provider”

Your billing provider is the system that holds the card and takes the money. EdgeKit connects it for your organization: its credentials, the notifications it sends to EdgeKit, and the first full read of its records. The console has no screen that connects or switches a billing provider.

Once connected, EdgeKit keeps a read-only copy of your billing provider’s accounts, prices, user subscriptions, invoices and transactions. The four Billing provider screens show it. EdgeKit never writes to it from the console. See Read your billing provider’s records.

Checkout charges through Recurly only. An organization whose active billing provider is anything else cannot sell through checkout yet. See Sell an offer with checkout.

From catalog to grant

Section titled “From catalog to grant”
  1. Create a product and choose its sites in Revenue › Catalog › Products.
  2. Create an offer for it in Revenue › Catalog › Offers, check that a billing provider price is mapped to it, and mark it Purchasable.
  3. Add an offer_token field naming the offer to an outcome in Revenue › Decision Engine › Outcomes. Each time a decision returns that outcome, the field carries a fresh offer token.
  4. Deploy.
  5. Your page takes the card with Recurly.js and calls the browser client’s checkout with the offer token, the card token and the buyer’s email. EdgeKit charges the card and writes the grant.
  6. From then on, renewals, pauses, failed payments and cancellations in your billing provider move the grant. See How access follows your billing provider.

The screens

Section titled “The screens”

The catalog screens, where you author:

  • Products, in Revenue › Catalog › Products: sites, coverage condition, capabilities and rank.
  • Offers, in Revenue › Catalog › Offers: merchandising, product, introductory discount, mapped prices and upgrade paths.
  • Capabilities, in Revenue › Catalog › Capabilities: key, label, quota unit, and the products that confer each one.

The Billing provider screens, which are read-only:

  • Billing accounts, in Revenue › Billing provider › Accounts.
  • Your billing provider’s products, prices, currencies, payment methods and coupons, in Revenue › Billing provider › Pricing.
  • Its user subscriptions, scheduled changes and usage records, in Revenue › Billing provider › Subscriptions.
  • Its invoices, line items, transactions and tax amounts, in Revenue › Billing provider › Invoicing.

Who can change the catalog

Section titled “Who can change the catalog”

Anyone in your organization can view the catalog and the Billing provider screens. Creating or changing a product, an offer or a capability needs the catalog write permission, which the Owner, Admin and Developer roles hold. Deploying needs the Owner or Admin role.

Next

Section titled “Next”