--- title: "Sign-in and payments on your site | Briks" url: https://briks.dev/docs/sign-in-and-payments description: "Give your site's visitors their own accounts and take one-time payments and subscriptions through your own processor, with every key kept on the site's server." last_updated: 2026-10-08 --- # Sign-in and payments on your site A site that needs accounts lets its own visitors sign up and sign in, and any site can take payments through a payment account of your own. This page covers both settings, what each provider and processor needs, where your keys are kept, where orders and members show up, how to sell plans that renew, and how shipping is built when you ask. 8 minute read Checked against the studio on 8 October 2026 ## Sign-in for your visitors Sign-in here means your site's own visitors: customers, members, clients, or your team on a dashboard. It is separate from the people in your workspace, who sign in to Briks itself, and the two never share accounts. A site that needs accounts, such as a members' area, a client portal or a dashboard, gets sign-up and sign-in by default. People make an account with their email address and a password, confirm the address from a link, and reset a forgotten password from an emailed link. Those emails go from your site's own address and count toward your [site email](https://briks.dev/docs/site-email) allowance for the month. To add accounts to a site that has none, ask for them in a change, such as “add a members' area where people sign up with their email”. Once that is published, the settings below apply to it. ## Switch on more ways to sign in Where 1. Projects 2. Your project 3. Settings 4. Sign-in Under **Ways to sign in**, **Email and password** is on by default. Below it are Google, Apple, Microsoft, GitHub, X, Facebook, LinkedIn and Discord, each letting people sign in with an account they already have. Each one uses an app you make in that provider's own console, with your own keys. 1. Open Sign-in Where: Settings, Sign-in Every way to sign in is listed with a switch, and **The site's addresses** lists each address your site answers on, with its main address first. 2. Set up a provider Where: Set up Press **Set up** beside the provider. The window lists the steps in that provider's console and the exact callback addresses to paste there, one for each address your site answers on, your own domain included. 3. Save its keys Where: Save keys Copy the keys from the provider's console into the fields and press **Save keys**. The provider is then marked **Keys on the site**. 4. Switch it on Where: Ways to sign in Turn the provider's switch on. It applies to the live site at once, with no build. At least one way to sign in always stays on. GitHub takes one callback address GitHub accepts a single callback address, so its button shows only on your site's main address. The other providers work on every address the site answers on. A provider that does not confirm email addresses itself has the address confirmed by a link first, and an account made with a provider is joined to an existing account only when both have confirmed the same address. ## Take payments Where 1. Projects 2. Your project 3. Settings 4. Payments Payments go straight to your own account with a payment processor. Buyers pay on the processor's own page, and refunds, tax and payouts stay in the processor's dashboard. Briks takes no fee on your sales; the processor's own fees apply. | Processors | How it switches on | What it can sell | | --- | --- | --- | | Stripe, PayPal, Mollie or Razorpay | On the live site at once, with no build | Digital goods, services, bookings and physical goods, with shipping built when you ask | | Paddle, Lemon Squeezy, Polar, Creem or Dodo Payments | A free republish adds it to that site only, in a minute or two | Software and digital products, under each processor's own rules. Each handles sales tax as the seller. | 1. Open Payments Where: Settings, Payments **Your payment processor** lists all nine, each marked **Not set up**, **Test keys** or **Keys on the site**. 2. Set up a processor Where: Set up Press **Set up** beside the one you use. The window lists the steps in that processor's dashboard, the webhook address to give it and, for Paddle, the checkout page address, then its key fields. 3. Save its keys Where: Save keys Paste the keys and press **Save keys**. Briks tries them with the processor first, and refuses keys that do not work. Test keys are marked **Test keys**, so you can try a payment before you take real money. 4. Switch it on Where: Your payment processor Turn its switch on. One processor takes payments at a time, so switching one on switches the other off. 5. Ask for something to buy Where: Studio The site takes payments where its pages have something to buy. Ask for it in a change, such as “sell the guides on the resources page” or “take a deposit with each booking”. Match the processor's currency Some processors charge in their store's or product's own currency. Once their keys are saved, **Payments** names that currency; keep the site's prices in it, or its checkout refuses the order. ## Where your keys are kept Every sign-in and payment key goes straight to your published site's own server as a secret. The studio keeps only the key's name, who saved it and when. **Settings**, **Secrets** lists those names tagged **Sign-in** or **Payments**, and they cannot be changed there. - **Publish first.** Keys are kept only on the published site, never by the studio, so they can be added after its first publish. - **Never shown again.** A saved key is not shown again. To change one, open the provider or processor and paste every key again. - **Addresses that move.** While a domain you added is on its way, each set-up says which callback addresses it will add and that the webhook address will move to it, so you can update the provider's or processor's console when it goes live. A key lost in an address move is marked **Enter the keys again**. ## Orders, members and your figures Each order appears in the project's **Database** tab under **Orders**: when it was ordered, what it was for, the amount, its state and the buyer. Search by email, what it was for or the order id, and filter by state. Nothing there changes an order: refunds are made in your processor's dashboard. People who made an account are listed under **Accounts** in the same tab, where an Editor or above can set a person's role to **Member**, **Staff** or **Admin**, or sign them out everywhere. See [Database](https://briks.dev/docs/database). Paid orders count in the site's [analytics](https://briks.dev/docs/analytics), under **Money and members**, with where those buyers came from. Sign-ups made with email and password count there too. ## Subscriptions A site can sell plans that renew every month or every year, with an optional free trial of up to 365 days, into your own payment account. Plans need Stripe, Paddle, Polar or Lemon Squeezy; PayPal, Mollie, Razorpay, Creem and Dodo Payments take one-time payments only for now. Briks takes no fee on what members pay; the processor's own fees apply. Add a plan 1. Set up a processor that sells plans Where: Settings, Payments Set up Stripe, Paddle, Polar or Lemon Squeezy as above. Its set-up window lists what plans need in the processor's own dashboard. For Polar and Lemon Squeezy, also give the ID of the monthly or yearly product a plan is charged as. A processor that is ready is marked **Sells plans**. 2. Ask for plans Where: Studio Ask for a membership or plans in a change, such as “add a monthly membership at £12 with a 7-day free trial, and keep the recipes page for members”. 3. Edit a plan Where: Database, Data Plans are records in your site's **plans** collection. Open it to change a plan or add one, as with any other record. 4. Watch them arrive Where: Database, Subscriptions Each member who subscribes shows under **Subscriptions**, beside **Orders**. Save test keys first if you would like to try a plan before taking real money. ### How members subscribe - **Signed in.** Members subscribe while signed in to the site, and pay on the processor's own page. - **Managing and cancelling.** Members manage or cancel their plan on the processor's own portal page. A cancelled plan runs to the end of the period paid for. - **Failed renewals.** While the processor retries a failed renewal, the member keeps access. - **Pages for subscribers.** Pages can be kept for subscribers, or for subscribers of one plan. Ask for it in a change. ### The Subscriptions view The project's **Database** tab has a **Subscriptions** view beside **Orders**: who subscribed, the plan, its state, and when it renews or ends. Above the list, the monthly income from running live plans is shown for each currency. Search by email, plan or subscription id, and filter by state. Nothing there changes a subscription: you cancel or refund in your processor's own dashboard. Connected Paddle, Polar or Lemon Squeezy before 21 October 2026? Add the new webhook events and permissions in your processor before you sell plans. Open the processor under **Settings**, **Payments**: its set-up steps list them. ## Dashboards and your team A dashboard's sign-in pages work like any site's. While it is a preview, anyone with its address can open it, so you can check it with its sample records. Once you publish it to production, only signed-in accounts with the **Staff** or **Admin** role see its data. Sign up on it with the email you use in the studio and you are its Admin; then give your team their roles under **Database**, **Accounts**. ## Shipping and physical goods - **Physical goods and shipping.** Physical goods can be paid for today through Stripe, PayPal, Mollie or Razorpay, like digital goods, services and bookings. Ask for shipping, delivery charges or stock, and Briks builds them into the site with your own payment account, its keys kept on the site's server under **Settings**, **Secrets**. A workshop with paid places A pottery studio in Totnes sells its Sunday wheel workshops > The owner saves her processor's test keys under **Settings**, **Payments**, switches it on, and asks in the Studio: Let people pay for a place on the Sunday workshop when they book, £95 each. Each booking goes on to the processor's own page to pay. Her own test booking shows under **Orders**; she then saves her live keys, and the next booking takes real money. ### Which plans include sign-in and payments? Every plan, Free included. There is no limit on visitor accounts or products, and Briks takes no fee on your sales. ### Who can change these settings? Owners and Admins save keys and switch providers and processors on or off. Everyone in the project can see the settings. ### Does switching a way to sign in need a build? No. Each sign-in switch applies to the live site at once. A site built before these settings reads them once a change or a free republish has gone out. ### Can I charge a monthly membership? Yes, monthly or yearly, with an optional free trial of up to 365 days, through Stripe, Paddle, Polar or Lemon Squeezy. See Subscriptions above. ### Can I use more than one processor? One at a time. Switching another on moves new payments to it. One from the second group needs a free republish first, and the site keeps taking payments with the old one until that has gone out. ## Read next - [Your site's features **Site email** Let your site send confirmations and replies from its own address on emails.briks.live, choose where replies go, and track sending against a monthly allowance.](https://briks.dev/docs/site-email) - [Data and automation **Database** Find what your site stores, edit and add records by hand, and download collections as JSON or CSV, with who can do what and the limits that apply.](https://briks.dev/docs/database) - [Data and automation **Secrets** Keep API keys and passwords your site's code needs on the site's server, never in pages or downloads. Add, change and remove them, and the rules Briks enforces.](https://briks.dev/docs/secrets) - [Building **Web apps and dashboards** What the App and Dashboard kinds build, where their records live, what is not available yet, with worked examples for bookings, stock and a café's orders.](https://briks.dev/docs/web-apps-and-dashboards) Still stuck? Write to [hello@briks.dev](mailto:hello@briks.dev) with your project's name and what you expected to see. A screenshot helps.