Let real end users in and take payments

Everything up to here worked without a brand domain or a payment account. Real end users sign in on a domain of yours, and real customers pay you, not ShipRev. This page covers both.

Your brand domain

End users sign up and sign in on your application's brand domain, for example account.example.com, through the hosted pages or the React components. The region picks your application, its appearance and its sign-in settings from the host name of each request, so the domain must be verified first.

In the operator console, under Settings, Customer sign-in:

1. Add the brand domain.
2. Publish the TXT record the console shows in your DNS.
3. Verify it. How long that takes depends on your DNS provider; it does not hold up anything you did on the previous pages.

The same domain also serves the public API that the React components call.

Three ways to connect your end users

The region runs the identity service behind every way: the account pool, password and social sign-in, invitations, email verification, password reset and the session tokens. What you choose is who owns the sign-in page and whether you want a ready-made set of self-service pages. All three are set under Customer sign-in.

To choose, ask in order: must the sign-in page be your own page, and will your team maintain it? Then way 3. Otherwise, does your application already show subscription and usage itself? Then way 1; if not, way 2.

Whichever way you choose, your backend checks every request with the Server SDK as described in Backend; the frontend never decides what an end user may do.

The React components

For ways 1 and 3, and for showing plans and usage inside your own interface, the @shiprev/react package provides sign-in and sign-up forms, a pricing table, a subscription panel and a usage meter.

npm install @shiprev/react@beta

The components send every request to a path on your page's own origin, which your server forwards to your brand domain under /rest. They store nothing: the sign-in form hands you the issued session, you keep it, and you give the access token back on every request, including the ones to your own backend.

import { ShipRevProvider, SignInForm, SignUpForm, PricingTable, SubscriptionPanel, UsageMeter } from '@shiprev/react';
import '@shiprev/react/styles.css';

export function App() {
  return (
    <ShipRevProvider apiBase="/shiprev" getAccessToken={getAccessToken} onUnauthorized={onUnauthorized}>
      {session ? (
        <>
          <UsageMeter />
          <SubscriptionPanel pricingUrl="#plans" />
          <PricingTable />
        </>
      ) : (
        <>
          <SignInForm onSignedIn={onSignedIn} />
          <SignUpForm onSignedUp={onSignedIn} />
        </>
      )}
    </ShipRevProvider>
  );
}

Registering with an unverified email address answers with a verification challenge; a 6-digit code is emailed, and from @shiprev/react 0.2.0-beta.0 on, which is not published yet, the forms ask for the code themselves and call onSignedIn only once it is confirmed. On 0.1.0-beta.0 the forms report the challenge through onError; until then, link registration and sign-in to the hosted pages.

Connect the account you are paid into

Customers pay you, not ShipRev. In the operator console, under Settings, Payment Gateway (the application's page in the developer console links to it as Payment settings), the application's payment connection has two forms:

Either way, charges are made on your Stripe account and ShipRev adds no application fee to them. Once connected, publishing a plan version creates the matching product and price on that account, versions published before the connection are synced then, and your end users' checkout and billing portal run on it.

Notes on a connected account:

• Several applications may connect the same Stripe account. Stripe keeps one authorization for the account, so disconnecting any of them stops payments for every application bound to that account at once; the confirmation says so. To stop one application only, switch it to another account or back to your own keys.
• The account's owner can also disconnect ShipRev in their Stripe Dashboard. The region checks every connected account periodically and stops the connection of an account it can no longer reach.
• The connection has to start on the host the operator console is opened on; if you are signed in elsewhere, the page tells you where to go.

Before you charge the first customer

• The brand domain is verified and reachable.
• A real end user can sign in and sees the plans you published.
• The payment connection is on the live account, or you are deliberately still in test mode.
• Your backend's guarded routes refuse a used-up allowance the way you expect, as rehearsed in A subscription in test mode.