Take payments with Stripe or PayPal

A table can take payments through Stripe or PayPal, with no code: the customer gets a link to pay an item, such as an order or an invoice, pays on Stripe's or PayPal's own page, and the item is marked paid once the provider says so. Setting it up is for the base's builders.

You need a Stripe account, a PayPal business account, or both. The base can hold one of them or the two; with the two, the customer picks how to pay. Base Captain takes no fee on these payments and never sees the card.

On the Free plan, a base takes payments once an owner adds a payment method, with no charge. Until then, Settings, Payments says so (What the Free plan includes).

To add Stripe to your base:

1. Click Settings, then Payments, and add Stripe.
2. Paste your Stripe key: a secret key, which starts with sk_, or a restricted key, which starts with rk_. A restricted key needs Checkout Sessions and Webhook Endpoints, and for payments that repeat and refunds also Subscriptions, Invoices, Refunds and Customer portal. A key that starts with sk_test_ or rk_test_ puts Stripe in test mode: no card is charged, and Stripe's test card 4242 4242 4242 4242 pays.
3. Save. Base Captain checks the key with Stripe: a key Stripe refuses is not saved, and the page shows Stripe's reason, such as "Stripe refused the key: Invalid API Key provided". Base Captain then adds the base's own webhook at Stripe, so Stripe tells the base of each payment. You add nothing in Stripe's dashboard and no secret by hand.
4. Stripe's page in Settings › Payments shows the Stripe account's name, whether it is in test mode and whether the webhook is on. Remove takes Stripe away from the base, and its webhook at Stripe with it.

PayPal works beside Stripe, or alone. To add PayPal to your base:

1. In PayPal's developer dashboard, make a REST app for your business and copy its client ID and its secret. The credentials of a sandbox app put PayPal in test mode: no money moves, and a sandbox buyer of PayPal pays.
2. Click Settings, then Payments, and add PayPal. Paste the Client ID and the Secret, and save.
3. Base Captain checks them with PayPal: credentials PayPal refuses are not saved, and the page says "PayPal refused the client ID and the secret". Base Captain then adds the base's own webhook at PayPal, so PayPal tells the base of each payment. You add nothing in PayPal's dashboard and no secret by hand.
4. PayPal's page in Settings › Payments shows whether it is in test mode and whether the webhook is on. Remove takes PayPal away from the base, and its webhook at PayPal with it.

After you add a provider, turn on payments on each table whose items are paid, such as the orders or the invoices.

1. In Builder, open the table, then its View items page. Under Payments, turn on Takes payments. While the base holds no provider, the section says to add one in Settings › Payments.
2. Pick its fields; each list offers only the fields that fit. Amount: a decimal field, such as the Total. Currency: the amount's own, or a choice or text field holding a code such as EUR. Customer's address: an email field of the item, or of the item a reference names, such as Customer › Email. Paid on: a date or date and time field, set once when the payment arrives.
3. Repeat: No for a single payment, or Each month or Each year for a payment that repeats, such as a membership's fee (Take a payment each month or year). A payment that repeats needs Paid until, a date field that shows how far the item is paid. It can also have Repeating, a yes/no field. The payment sets it to yes when the repeating payment starts and at each charge, and to no when the customer, your staff, Stripe or PayPal stops it. Users cannot change it.
4. Pick the roles of your team that may ask for payment on the table's items, see their payments, stop a payment that repeats and give a payment back. With no role picked, only the admins may. A role of your customers cannot be picked.
5. Click Save table.

In a base with the Invoices module, the invoices need no step in Builder: they take card payments as soon as the base holds Stripe or PayPal. Every app with the Invoices module does this, such as Invoices and payments.

• An unpaid invoice takes card payments: one that is Sent or Overdue, and, in an app with reminders, one that is Drafting a reminder, Reminder to check or Reminder sent. A draft, an invoice To approve, a paid invoice and a cancelled one do not.
• On an unpaid invoice, the admins see Ask for payment among the invoice's buttons, which mails the payment link to the customer's address, and Copy the payment link in its More actions menu, which gives the link with no mail (Ask a customer to pay with a payment link).
• A customer who signs in to your portal sees their own invoices, and Pay on each unpaid one. A customer who does not sign in opens the link in the mail and pays from it. With Stripe and PayPal both, the customer picks one.
• Each card payment is a row of Online payments (See every payment in Online payments). The invoice then gets a payment for what was left to pay, with the method Card, and its status is Paid.

While the base holds Stripe or PayPal, each unpaid item of a table that takes payments offers two actions to the roles of the table's payment, on the item's page. An item is unpaid when it has no paid date and an amount above zero; for a payment that repeats, while its amount is above zero and no repeating payment runs on it.

• Ask for payment, a button of the item, mails the customer a link of your base to pay the item (a payment link), and then names the customer's address it mailed.
• Copy the payment link, in the item's More actions menu, copies the same link, to send it yourself, in a chat or a text message. It sends no mail.

The link works for 30 days. It opens a page of your base with Pay; each Pay opens a fresh page of Stripe or PayPal, so a customer who comes back later can still pay. A customer with a role of your customer portal sees Pay on the item's own page too, on an unpaid item they see (Open a customer portal).

When the base holds both providers, there is one button for each, Pay with Stripe and Pay with PayPal, and the customer picks one. With PayPal, the customer approves the payment on PayPal's page and comes back to your base. A provider in test mode says Test mode beside its button.

A public form on a table that takes payments can ask the visitor to pay right after they send it, such as a deposit with a booking: turn on Ask the visitor to pay in the form, under the table's Forms. The switch shows only on a form whose table takes payments. The base makes the item, the visitor clicks Pay and pays on Stripe's or PayPal's page, and the form's thanks comes after the payment. A visitor who leaves without paying leaves an unpaid item, and your team can ask for payment on it later. In a frame on your own website, Pay opens a new tab (Take a payment with a public form).

The example shop's orders show what happens when a customer pays:

1. Signed in as a manager, open a pending order and click Ask for payment. Base Captain names the customer's address it mailed the link to.
2. The customer gets a mail with the amount and the link, opens it and clicks Pay.
3. The customer pays on Stripe's page and lands on a page of your base that reads "Payment received". The order's Paid at is set, and its history shows the change by Stripe, with a note such as "Paid by card through Stripe: USD 120.50." The shop's automation Order paid: mark it paid then sets its status to Paid, and the buttons are gone.

With PayPal, the history shows the change by PayPal, with a note such as "Paid through PayPal: EUR 120.50."

When the customer comes back from Stripe's or PayPal's page, Base Captain also asks the provider whether the payment went through, so a payment is not lost when the provider's message comes late or not at all.

A payment that repeats each month or each year (a subscription) starts when the customer clicks Pay each month or Pay each year once, on the link or on the item's page in your portal, and gives the card on Stripe's page, or approves the repeating payment on PayPal's page. With both providers, the buttons say which one, such as Pay each month with PayPal. The provider then charges the amount each period by itself, until someone stops it. Base Captain keeps no card and charges nothing by itself.

• Each charge adds a row to Online payments and moves the item's Paid until to the end of the period paid. The item's history shows each one, by Stripe, with a note such as "Paid by card through Stripe: EUR 49.00, until 2026-12-20.", or "Paid through PayPal: EUR 49.00, until 2026-12-20." The paid date, when the table names one, is set at the first charge only.
• An automation on Paid until does what your base needs, such as telling your staff when a membership is not paid a week after its paid until date. An automation that also reads Repeating tells only the customers whose payment still repeats that their card is charged soon.
• When the customer's payment fails, Stripe tries again for some days, and PayPal tries again until three charges have failed. When the provider stops trying, the payment stops, Online payments has a row "Stopped after failed charges", the history says "Stripe stopped the repeating payment after failed charges." or "PayPal stopped the repeating payment after failed charges.", and Paid until stays where it was. When Paid until has passed, the item shows its Pay button again, Pay each month or Pay each year, so the customer can pay another way.

While the payment repeats, the item shows no Pay and no Ask for payment. When it stops, they show again once Paid until has passed. An item that you mark paid yourself, with no Paid until, shows no Pay. The Memberships module's memberships take a monthly payment this way, and the Club dues app's dues a yearly one.

A payment that repeats stops when one of these people stops it:

• Your staff, with the roles of the table's payment: Stop the repeating payment on the item, then confirm.
• The customer: Stop the repeating payment on their payment link, or on the item's page in your portal. The history says it was stopped by the customer.

The provider charges no more from that moment, and gives nothing back: Paid until stays, so the period paid stays paid. Repeating, when the table has it, changes to no. A payment stopped at Stripe or at PayPal, in its dashboard or by the customer's PayPal account, stops in the base too.

Change the card

With Stripe, the customer changes the card themselves: Change the card, on their payment link or on the item's page in your portal, opens Stripe's own page for it, which then brings them back. With PayPal, there is no Change the card: the customer changes how they pay in their own PayPal account. Your staff never see or enter a card.

Each payment is a row of Online payments, a list under Activity in the rail. The list shows each payment's item, by its name when it was paid, its table, the amount and the currency, the state and the amount refunded for a part, the provider and its reference, when it was paid, and Refund. A row also holds the repeating payment it belongs to, if any. Its state is Paid, Refunded, or Stopped after failed charges. Click a row to open the item.

Nobody adds or deletes a row: the base writes it when the payment arrives, once, and a refund changes it. The base's builders see every row, and each role of your team the rows of the tables whose payment names that role. Your customers never see the list.

Your staff with the roles of the table's payment refund a payment from its row of Online payments, all of it or a part:

1. Click Activity, then Online payments, and click Refund on the row.
2. The dialog names the payment it refunds: the paid item and its table, the amount paid, when it was paid, and the provider with its reference, so that two payments of one item and amount tell apart. It shows the amount that is left to refund, and offers all of it. Type a smaller amount to give back a part. More than what is left is refused, and the dialog then shows the amount that is left now, once. An amount with more decimals than the currency has (2 for US dollars, 0 for Japanese yen) is refused too: it is never rounded.
3. Confirm. The base gives the money back through the provider that took it, Stripe or PayPal, which sends it back to the customer.

The row shows the amount refunded. Its state is Refunded when all of it is given back, and stays Paid for a part. The paid item's history says who refunded what, such as "Refunded through Stripe: EUR 20.00." or "Refunded through PayPal: EUR 20.00." The item's paid date stays, so the automations on it do not run again. If the provider refuses, the dialog shows its reason and nothing changes. Only a row with something left to refund shows Refund.

The assistant sets up a table's payments for you, with no code, once the base holds Stripe or PayPal.

1. Add Stripe or PayPal yourself, in Settings, Payments, with your Stripe key or your PayPal REST app's client ID and secret (Add Stripe to your base). The assistant never enters a key: it tells you to add a provider there when the base has none.
2. Ask the assistant, for example: "Let customers pay their invoices by card." It sets which fields of the invoices hold the amount, the currency, the customer's address and the paid date, and which roles may ask for payment, with no code. Ask "Let members pay their membership each month" for a payment that repeats: it also sets the paid until date field, and the repeating yes/no field when the table has one. Click Apply. Ask for payment and Copy the payment link come with it.

In a base with the Invoices module, the invoices take cards with no request (Take card payments on invoices).

Take payments with the assistant

The assistant can then ask for payment on an item for you, "Ask the customer to pay invoice INV-0042", or give you its payment link, under your role, as the buttons do. It also stops a payment that repeats, "Stop the monthly payment of Anna's membership", and gives a payment back, all of it or a part, "Refund EUR 20 of that payment", when your role may. Only the customer changes the card, on Stripe's page, or how they pay, in their PayPal account. Your AI connected to Base Captain's MCP server can do the same. The assistant reads the base's Online payments as it reads any list you may see.

Payments have these limits:

• The paid date is set once: if the provider tells the base twice, the second time changes nothing, and neither does a call that does not come from the provider, or a payment it declines.
• A payment for an item that was already paid, or whose amount changed after the customer opened the provider's page, does not set the paid date. The item's history notes it, such as "Paid by card through Stripe: USD 662.00. The order was already paid, so this payment needs a look."
• The base sends no receipt of its own: an automation on the paid date sends one, as the modules' automations do, and Stripe can send its own if you turn it on in Stripe.
• Instead of a link, Ask for payment says what to fix: "Nothing to pay", "No address to mail the payment link to", "Already paid", or "No payment provider: add one in Settings › Payments".
• A button of your own asks for no payment: to set a status and then ask, make the button and an automation that asks when the status changes.

An automation can ask for payment too (Run actions when an item changes), and a customer link to the printed item shows Pay while the item is unpaid (Send a printed item to a customer by link).

Under an API token, an unpaid item's payment says what its user may do:

• POST /api/tables/<table>/items/<id>/payment/ask and …/payment/link do what the two buttons do;
• a customer's …/payment/pay takes the provider, stripe or paypal, when the base holds both;
• …/payment/stop stops a payment that repeats;
• POST /api/tables/_online_payments/items/<id>/refund gives a payment back, all of it or the amount you send.

The assistant does all of these too, when you ask it, under your role, and so does your AI connected to Base Captain's MCP server (Set up and take payments with the assistant).