Solo beauty Stripe glossary: 18 payment terms booth renters should know (2026)

Stripe Standard account

The default account type created when a solo operator signs up at stripe.com. A Standard account is owned and controlled entirely by the operator: they log in directly with their own email and password, see all transactions in their Dashboard, and receive payouts directly to their linked bank account. The operator is the merchant of record — the entity responsible for the transaction from Stripe's perspective.

In a BYO-Stripe platform model (like ChairHold), the operator connects their existing Standard account to the platform. No new account is created by the platform; the operator's account is linked through an OAuth authorization flow. This is the structural source of all the portability advantages of BYO Stripe: because the account is Standard and operator-owned, the customer objects, transaction history, and payout history all live in the operator's account — not inside a platform's account that the operator cannot access independently.

Standard accounts have the same fee structure as any Stripe account: 2.9% + $0.30 per successful card transaction in the US. There is no revenue share built into Stripe at the account level for Standard accounts — if a platform adds a processing margin on top of the Stripe rate, that is a platform decision, not a Stripe structural requirement. ChairHold does not add a processing margin; the operator's own Stripe rate applies. See the Stripe fee math post for the full cost calculation for deposit collection.

Stripe Connect

Stripe's multi-party payment infrastructure that allows a platform to move money between multiple parties — typically between end customers, operators, and the platform itself. In a Stripe Connect arrangement, the platform creates a "platform account" (the platform's own Stripe account) and links individual operators as "connected accounts." The platform can then collect payments on behalf of operators, take a platform fee, and pay out the remainder to the operator's connected account.

There are three types of connected accounts: Standard (fully operator-owned and controlled; same as a normal Standard account but linked to the platform), Express (Stripe manages onboarding and the hosted dashboard; the platform has more control over settings), and Custom (fully platform-controlled; the operator may not have direct Stripe Dashboard access at all). The choice of account type determines how much access and control the operator has over their own payment data.

Most full-calendar booking platforms that handle payments on behalf of operators use some form of Stripe Connect behind the scenes. This is why operators on those platforms do not own their Stripe customer objects: the transactions live in the platform's Stripe account (or in the platform's connected account infrastructure), not in an account the operator controls. When the operator leaves the platform, they cannot take the Stripe customer records with them — those objects belong to the platform's account.

ChairHold v1 does not use Stripe Connect. The integration is direct: the operator's Standard account is used for all transactions, with ChairHold requesting only the permissions needed to create Checkout sessions on the operator's behalf. This is why client portability is a structural property of ChairHold — not a feature that could be removed by a policy change. The operator's Stripe customer objects are in the operator's account from the first deposit. The client data export post covers what data is exportable from Connect-based platforms vs BYO-Stripe platforms and why the difference matters when switching tools.

Stripe Express account

A variant of Stripe Connect in which Stripe manages the dashboard UI and KYC (Know Your Customer) identity verification, while the platform has more control over payout settings and some account parameters than it would with Standard Connect. Express accounts look and feel like normal Stripe accounts from the operator's perspective — there is a Stripe-hosted dashboard at express.stripe.com where the operator can see their balance and payout history — but the platform can configure payout schedules, enable or disable certain features, and in some cases delay payouts.

Some booking platforms that advertise "your own Stripe account" are actually issuing Express connected accounts, not linking to the operator's existing Standard account. The key test: can you log into dashboard.stripe.com (not express.stripe.com) using the credentials you use for booking-related deposits? If the booking-related deposits appear in your main Stripe Dashboard, you have a Standard account linked via OAuth. If you need to log into a separate dashboard or access payments through the platform's portal, you may have an Express account.

The practical implication: Express accounts may still offer some portability (Stripe allows data export from Express accounts in many configurations), but the platform has more control over the relationship than in a Standard OAuth link. The operator's leverage — ability to revoke access, switch platforms without losing customer data, and see transactions independently — is lower with Express than with Standard.

Stripe customer object

A structured record in Stripe that stores a specific customer's identity, payment methods, and transaction history. Each customer in Stripe has a unique ID beginning with cus_ (for example, cus_QX7kP2mNjLw4). The customer object is the anchor for everything Stripe tracks about that person: their email address, attached payment methods (card tokens, bank accounts), billing address, and the list of Payment Intents and charges associated with them.

Customer objects are the basis for client portability in BYO-Stripe platforms. When a client pays a deposit through ChairHold, a cus_ object is created in the operator's Stripe account with that client's email and payment method attached. That object belongs to the operator's account. If the operator later migrates to a different tool that also uses BYO Stripe, they can export their full customer list from the Stripe Dashboard — including all attached payment methods — and import it into the new tool. The client's card information is already in Stripe; they do not need to re-enter it.

On platforms that use their own payment processing (Booksy, Fresha's integrated payments, Square's processing layer), customer objects are created in the platform's Stripe account, not the operator's. When the operator leaves the platform, they can export client names and emails (usually) but not payment method tokens — those tokens are owned by the platform's Stripe account. The client must re-enter their card on a new platform. The client data export post maps exactly which fields are exportable from Booksy, Fresha, and Square vs a BYO-Stripe configuration.

Payment Intent

The Stripe object that represents a single attempt to collect payment. Creating a Payment Intent tells Stripe "I intend to charge this customer this amount in this currency." The Payment Intent tracks the payment's lifecycle through a series of states: requires_payment_method (no card yet), requires_confirmation (card attached, waiting to proceed), requires_action (3DS authentication step needed), processing (charge in flight), and succeeded (payment complete). Each state transition is recorded on the object and triggers corresponding webhook events.

Every deposit collected via Stripe Checkout creates a Payment Intent behind the scenes. The Payment Intent ID (beginning with pi_) is the primary reference for a specific charge — if an operator needs to look up a transaction, issue a refund, or respond to a dispute, they find the Payment Intent in their Stripe Dashboard and work from there. When a dispute is filed against a charge, the dispute is linked to the Payment Intent's underlying charge object.

Payment Intents have two capture modes: automatic (funds are captured immediately when the payment succeeds, which is the default and what ChairHold uses) and manual (the card is authorized but not charged until the operator explicitly calls the capture endpoint, within 7 days). The distinction between automatic and manual capture determines whether the platform does "deposit collection" (automatic capture) or "authorization holds" (manual capture with optional release). See the Stripe capture vs authorization post for the full trade-off analysis.

Setup Intent

A Stripe object that saves a customer's payment method for future use without immediately charging them. Unlike a Payment Intent, a Setup Intent collects zero dollars — it only stores the card credentials in the Stripe customer object so that a future charge can be initiated without the client re-entering their card number. The Setup Intent goes through its own authentication flow (including 3DS if required) at save time, so the client authenticates once at booking rather than again at the point of charge.

Setup Intents are the backbone of "save your card, pay later" models — for example, a platform that books the appointment, saves the client's card, and then charges the full balance after the service. This is a different model from deposit-first collection: instead of charging a deposit upfront, the platform saves the card and charges it after the fact. The risk profile is different: with a deposit upfront, the operator has funds in hand from the moment of booking; with a save-and-charge model, the operator is relying on the ability to charge the card post-service, which can fail (insufficient funds, card reported stolen, client disputes the charge as unauthorized).

For solo beauty deposit collection, the direct upfront deposit (Payment Intent with automatic capture) is the model that most reliably reduces no-shows, because the client has actually parted with money at booking time. A Setup Intent that only saves the card does not trigger the same psychological commitment — the client has not yet paid anything. The distinction matters when evaluating platforms that describe their model as "deposit collection" but actually use a save-and-charge flow.

Stripe Checkout

Stripe's hosted payment page — a pre-built, Stripe-hosted page that handles the payment UI, card entry, 3DS authentication, Apple Pay, Google Pay, and confirmation receipt. Operators create a Checkout session via the Stripe API, which returns a URL (beginning with checkout.stripe.com). The client is redirected to that URL, completes payment on the Stripe-hosted page, and is redirected back to the operator's site after success or cancellation.

Checkout is the simplest and most secure way to collect payment without building a custom payment UI. Because the card entry happens on Stripe's domain, the operator's server never touches raw card numbers — PCI compliance is handled by Stripe. Checkout supports all major card networks, Apple Pay, Google Pay, and dozens of local payment methods internationally. ChairHold uses Stripe Checkout for all deposit collection: operators get full Stripe payment security with no payment-UI code to maintain.

Checkout sessions have a configurable expiration (default 24 hours). If a client starts the Checkout flow but does not complete payment before expiration, the session expires and a new one must be created. This is the mechanism behind ChairHold's time-to-live for deposit links — the slot is held open for a defined window (10 minutes in ChairHold's design), after which the Checkout session expires and the slot is released if the deposit was not completed. The solo beauty booking glossary covers time-to-live in the context of deposit-first UX.

Stripe payout schedule

The timeline from when a payment is received in a Stripe account to when the funds are transferred to the operator's bank account. Stripe's default payout schedule for US accounts is T+2: funds from a payment processed today arrive in the linked bank account two business days later. This is an automatic daily sweep — Stripe aggregates the day's settled transactions and initiates the bank transfer automatically.

Two alternatives to the default T+2 schedule: Instant Payouts, available for an additional 1% fee (minimum $0.50, maximum $10), which transfer funds to an eligible debit card or bank account within minutes. And manual payouts, where the automatic daily sweep is disabled and the operator initiates payouts manually on demand — Stripe holds the account balance indefinitely until a payout is requested. Manual payouts are useful for operators who want to control exactly when funds move, or who aggregate deposits over a service period before sweeping to their bank.

The T+2 default payout schedule is structurally faster than most platform-mediated payout systems. Booksy and Fresha, which process payments through their own payment infrastructure, pay out on platform-controlled weekly cycles — operators may wait up to 7 days for funds from a payment collected at the start of the week. Square's standard payout schedule is next-business-day (T+1) for most transactions, which is faster than Booksy and Fresha but still slower than Stripe's Instant Payout option. For solo booth-rental operators managing tight cash flow, payout timing is a real operational variable — not just a feature footnote.

Stripe fee structure

The cost Stripe charges for payment processing. The US standard rates for 2026:

• Card transactions (online): 2.9% + $0.30 per successful charge. This applies to all major credit and debit cards processed via Stripe Checkout or the API.
• ACH debit: 0.8% per transaction, capped at $5.00. ACH is cheaper than card for deposits above $625 (where 2.9% would exceed $18.12). The trade-off: ACH takes 2–3 business days to settle, and ACH disputes work differently from card disputes (clients can initiate ACH reversals for up to 60 days for unauthorized transactions, vs the shorter card dispute window).
• International cards: +1.5% surcharge above the base rate for cards issued outside the US. Cards that require currency conversion add an additional 1%. A UK client paying with a UK-issued card would pay 2.9% + 1.5% + $0.30 = 4.4% + $0.30.
• Dispute fee: $15 debited from the account when a dispute is filed. If the dispute is resolved in the operator's favor, the fee may be partially refunded (the Stripe portion; card-network fees vary).
• Refund fee: No fee to initiate a refund. However, the original processing fee (2.9% + $0.30) is not returned when a refund is issued — only the net settlement amount is reversed. An operator who collects a $100 deposit and then fully refunds it has lost approximately $3.20 in processing fees.

Stripe does not charge a monthly subscription fee on basic card processing — the cost is entirely transaction-based. Platforms that use Stripe as their backend but charge a processing margin on top of the Stripe rate (e.g., 0.5%–1.0% additional) effectively pass a higher rate to operators without Stripe being the reason. The Stripe fee math post works through the full cost calculation for a solo operator collecting $50k/yr in gross bookings with a 30% deposit requirement.

Authorization hold

A temporary reservation of funds on a client's card without actually capturing (transferring) the money. In Stripe, this is implemented via a Payment Intent with capture_method: manual. The card is authorized for the specified amount — the client's available credit is reduced, and the authorization appears as a pending charge on their statement — but no funds change hands until the operator explicitly calls the capture endpoint. If the operator releases the authorization instead of capturing, the hold disappears from the client's account within a few days and no money was ever transferred.

Authorization holds expire automatically after 7 days in Stripe. If the operator does not capture the funds within 7 days, Stripe automatically voids the authorization and releases the hold. This creates an operational deadline: a "hold the slot for no-shows" model requires the operator to actively capture (or release) within the 7-day window, or the authorization expires and the no-show cost is unrecoverable.

The authorization-hold model is structurally different from upfront deposit capture. With upfront capture: the client's card is charged immediately at booking; the operator has the funds; the client has parted with money. With an authorization hold: the client's card is authorized but not charged; the operator can charge it but has not yet; the client has a pending hold on their credit limit but no actual payment. Research on no-show reduction consistently shows that upfront deposit capture is more effective than authorization holds at reducing no-show rates — the commitment signal of an actual payment is stronger than a pending hold. Some platforms describe their model as "deposit collection" but implement it as authorization holds; operators should verify which mode is used. The Stripe capture vs authorization post covers the full comparison, including the dispute mechanics that differ between the two approaches.

Refund

An operator-initiated return of funds to a client. A refund is the operator's voluntary decision to return part or all of a payment — it is initiated by the operator through the Stripe Dashboard or API, not by the client or their bank. Refunds can be full (return the entire charged amount) or partial (return a specific dollar amount, for example a partial refund when the client rescheduled within the refund window).

Stripe does not charge a fee to issue a refund, but the original processing fee is not returned. An operator who charges a $60 deposit (paying ~$2.04 in Stripe fees) and then fully refunds it receives $60 back from Stripe but retains the $2.04 processing cost — it is not reversed. For partial refunds, only the proportional processing fee for the refunded portion stays with Stripe; the rest of the processing fee is also retained by Stripe (not refunded).

Refunds typically return to the client's card within 5–10 business days. The key strategic point for deposit collection: if a refund is warranted (for example, the operator cancelled the appointment, or the client cancelled within the refund_window_hours), issue the refund proactively in the Stripe Dashboard before the client files a dispute with their bank. A proactive refund is always cheaper than a dispute — there is no $15 dispute fee, no evidence submission process, and no waiting period. If the operator has already issued a refund and the client still files a dispute, the operator can submit the refund evidence and almost always prevail. The chargeback response post covers the evidence structure for both "refund already issued" and "deposit was non-refundable per disclosed policy" dispute types.

Dispute / chargeback

A client-initiated reversal of a charge, filed through the client's bank or card issuer rather than through Stripe or the operator. When a client disputes a charge, their bank removes the funds from the operator's Stripe account while the dispute is under review, and adds a $15 dispute fee. The operator has a response window — typically 7–21 days depending on the card network — to submit evidence. If the dispute is decided in the operator's favor, the funds are returned. If the dispute is lost, the client keeps the reversal and the operator absorbs both the lost deposit and the $15 fee.

The most common dispute reasons in solo beauty deposit collection: "I didn't authorize this charge" (often from clients who forgot the booking or are attempting friendly fraud); "services not rendered" (no-show disputes where the client argues they should receive their deposit back regardless of policy); and "not as described" (service quality or appointment-logistics disputes). Each reason code has a different optimal evidence set. For "I didn't authorize this," the key evidence is the Stripe transaction log showing the card was successfully 3DS-authenticated (if 3DS was used) — a completed 3DS authentication essentially ends this dispute category. For "services not rendered," the key evidence is the booking confirmation, the pre-payment disclosure of the cancellation policy, and any communication showing the client acknowledged the policy.

The term "chargeback" and "dispute" are often used interchangeably in practice. Technically, the dispute is the event (the bank's investigation); the chargeback is the outcome (the reversal of funds). Some platforms distinguish between "retrieval requests" (the bank asking for information before deciding whether to issue a chargeback) and "chargebacks" (the formal dispute with funds reversal). In Stripe's Dashboard, all of these appear under "Disputes." The chargeback response post walks through the full evidence submission process for the three most common dispute types in solo beauty.

Stripe Radar

Stripe's built-in fraud detection and rule engine. Radar evaluates every payment attempt against a machine-learning fraud model trained on Stripe's network-wide transaction data, and against a set of rules the operator can configure. By default, Radar blocks payments that score above a fraud threshold determined by Stripe's ML model. Operators can add custom rules to block, allow, or require additional authentication for payments that meet specific criteria.

Custom Radar rules use a simple conditional syntax. Common rules for solo beauty deposit collection:

• block if :card_country: != 'US' — blocks cards issued outside the US. Useful for operators who only serve local clients and see international card charges as inherently suspicious.
• block if :is_anonymous_ip: — blocks VPN and proxy traffic, which is associated with higher fraud rates. Clients booking through a VPN for privacy may be inadvertently blocked.
• request_three_d_secure if true — requires 3DS authentication on all transactions, shifting liability for any "I didn't authorize this" dispute to the card issuer. This is the most effective Radar rule for solo beauty operators who handle high-ticket services.
• request_three_d_secure if :card_funding: = 'prepaid' — requires 3DS specifically for prepaid cards, which have higher fraud rates and weaker chargeback protections for operators.
• block if :customer_id: in ['cus_xxx', 'cus_yyy'] — blocks specific customers by their Stripe customer ID. Useful for blocking known problem clients after a dispute or no-show pattern.

Rules are written and managed in the Stripe Dashboard under Radar → Rules. The Stripe Radar rules post covers the full rule set for solo beauty deposit collection, including the trade-off between blocking international cards (higher fraud protection, potential false positives) and requiring 3DS (liability shift without blocking legitimate clients).

Stripe 3D Secure (3DS2)

An authentication step in which the cardholder's bank verifies their identity during a payment before the charge is processed. 3DS2 (the current version, also called "3D Secure 2") typically presents as a push notification in the cardholder's banking app, a biometric prompt (Face ID, fingerprint), or a one-time code — replacing the older 3DS1 password step. The authentication takes a few seconds and is invisible to the operator; the client sees it as part of their banking app experience.

The critical property of 3DS is liability shift: if a payment is successfully authenticated via 3DS and the client later disputes it as unauthorized ("I didn't make this purchase"), the liability for that dispute shifts from the merchant to the card issuer. In practice, this means a "I didn't authorize this" dispute on a 3DS-authenticated payment is almost always decided in the operator's favor — the bank's own authentication system verified the cardholder's identity, so the bank, not the operator, is responsible for an unauthorized claim.

For solo beauty deposit collection, enabling 3DS via Radar (request_three_d_secure if true) converts the most common dispute reason — "I didn't authorize this" — from an operator risk into a bank risk. The trade-off: 3DS adds a step to the checkout flow. Some clients (especially older clients or those with less active banking apps) may abandon the checkout if they cannot complete the 3DS authentication. For high-ticket appointments (PMU, full color, lash extensions) where a single dispute costs the operator $150–$400 in lost deposit plus the $15 fee, the liability shift justifies the marginal checkout friction. For lower-ticket deposits ($25–$50), the operator may decide the friction cost outweighs the protection. The Radar rules post discusses which verticals benefit most from always-on 3DS.

3DS is mandatory in some jurisdictions under Strong Customer Authentication (SCA) regulations, including the European Economic Area and the UK. For US-only operators, 3DS is optional and operator-requested via Radar rules.

Stripe webhook

A system for Stripe to push event notifications to the operator's server in real time. When something happens in Stripe — a payment succeeds, a refund is issued, a dispute is created, a payout completes — Stripe sends an HTTP POST request to a URL the operator specifies (the "webhook endpoint"). The request body is a JSON object containing the event type and the full associated Stripe object.

Webhooks are how booking platforms know that a payment has completed. When a client finishes paying a deposit in Stripe Checkout and is redirected back to ChairHold, two things happen simultaneously: the client sees a success page (a client-side redirect from Checkout), and Stripe sends a payment_intent.succeeded webhook event to ChairHold's server. The booking confirmation — the SMS reminder, the appointment record in the database, the operator notification — is driven by the webhook event, not by the client-side redirect. This is important for reliability: the client-side redirect can be interrupted (bad network, closed browser tab), but the webhook event from Stripe arrives regardless.

Operators on BYO-Stripe platforms do not need to manage webhooks themselves — the platform handles the webhook integration. But understanding that webhooks exist explains why deposit confirmation is reliable even when clients have connectivity issues during checkout: Stripe delivers the event server-to-server, independent of the client's browser.

For operators who build their own Stripe integrations or who want to receive additional notifications, webhooks can be configured at dashboard.stripe.com → Developers → Webhooks. Stripe requires webhook endpoints to return an HTTP 200 within 30 seconds; if no response is received, Stripe retries up to 3 times with exponential backoff.

Stripe Dashboard

The web-based management interface at dashboard.stripe.com where operators can view and manage all aspects of their Stripe account: transaction history, payouts, customer records, disputes, refunds, Radar rules, API keys, and account settings. Operators log in with their own email and password — no third-party access required.

The Stripe Dashboard is the ground truth for Stripe transactions. If a platform reports different revenue numbers than the Stripe Dashboard (due to payout timing differences, fees applied by the platform, or refunds processed outside the operator's view), the Stripe Dashboard numbers are the authoritative record of what actually happened at the payment level.

Dashboard access is the clearest indicator of account ownership. Operators on Standard Stripe accounts linked via BYO to a platform can always log into their Dashboard independently and see all transactions, regardless of what the platform reports. Operators whose payments flow through a platform's own payment system do not have Stripe Dashboard access for those transactions — the transactions live in the platform's account. This asymmetry in transparency is one of the practical reasons BYO Stripe matters for operators who want to verify their own revenue independently.

From the Dashboard, operators can also view their Stripe customer objects (under Customers), see which platforms have connected access to the account (under Settings → Connected Applications), and revoke access from any connected application at any time.

Stripe API keys

The credentials used to authenticate requests to the Stripe API. There are two types: the publishable key (beginning with pk_live_ in production) and the secret key (beginning with sk_live_). The publishable key can be safely included in client-side JavaScript — it identifies the Stripe account and can be used to create Checkout sessions and set up payment methods, but it cannot initiate server-side operations like charges, refunds, or customer record modifications. The secret key must never leave the server — it has full access to the account and can move money, issue refunds, and access all account data.

Stripe also offers restricted API keys, which are subsets of the secret key with specific permissions scoped to particular resources (for example, a key that can only read customer records but not create charges). Restricted keys are useful for giving third-party tools limited access without granting full account control.

Test-mode keys (beginning with pk_test_ and sk_test_) operate against Stripe's test environment, where card number 4242 4242 4242 4242 (any future expiry, any CVC) succeeds every time, and 4000 0000 0000 0002 is always declined. Test-mode transactions do not move real money and do not appear in live-mode reports. This allows operators and platform developers to test their integration fully before going live.

Operators connecting a BYO-Stripe account to a booking platform via OAuth do not share their API keys directly. Instead, the OAuth flow generates a platform-specific access token that grants scoped permissions — the operator never gives the platform their sk_live_ key, and the operator can revoke the OAuth connection from their Dashboard at any time, immediately terminating the platform's API access.

Stripe Connect OAuth

The authorization flow that allows a BYO-Stripe platform to access an operator's existing Standard account securely, without the operator sharing their API keys. The flow:

1. The operator clicks "Connect your Stripe account" in the booking platform.
2. They are redirected to stripe.com and authenticate with their Stripe credentials.
3. Stripe shows them a permissions screen listing exactly what the platform is requesting access to (e.g., "Create charges on your behalf," "View customer records").
4. The operator approves the permissions, and Stripe redirects back to the platform with an authorization code.
5. The platform exchanges the code for an access token that grants scoped access to the operator's account, valid indefinitely (or until the operator revokes it).

The permissions granted are specified by the platform and shown to the operator during step 3. A minimal BYO-Stripe integration might request only "create Checkout sessions on your behalf" — enough to collect deposits, nothing more. A more expansive integration might request read access to customer records, the ability to issue refunds, or webhook configuration. Operators can review exactly what permissions any connected platform has from their Stripe Dashboard under Settings → Connected Applications, and can revoke access at any time with a single click — immediately and irrevocably cutting the platform's API access to the account.

The OAuth flow is the mechanism that distinguishes "genuine BYO Stripe" (Standard account connected via operator-approved OAuth) from "platform-mediated payments that happen to use Stripe on the backend." In the first case, the operator granted specific permissions and can revoke them. In the second case, the operator has no OAuth connection to review or revoke — the platform's Stripe account is the one doing the charging, and the operator's only relationship is to the platform, not to Stripe.