Payments and Checkout

This guide covers the payment settings on the Commerce tab of Settings → Business Settings: the Payments & Checkout section, the Stripe & Payouts section (only shown when you bring your own Stripe account), and the Fixed Price section. Fees and commission are covered separately in Fees, commission and sales models.

Before you start

• You need permission to manage business settings. See Team members and roles.
• If you plan to use your own Stripe account, have your Stripe Dashboard open with access to both your test and live API keys.
• Nothing is saved until you click Save Settings at the bottom of the page. Saving writes every tab at once.
• Configuring payments is a required item on your launch readiness checklist. It counts as done once your payment mode is Offline Only, or once a publishable and secret key are available for the Stripe environment in use. See Getting started.

Payments & Checkout

Go to Settings → Business Settings → Commerce → Payments & Checkout.

Payment Mode

Decides who runs checkout, whose Stripe account takes the money, and how seller payouts are made. The default is Babylon Managed.

• Babylon Managed (Babylon's managed Stripe account, operated by Babylon): checkout and card capture use the platform's Stripe account and keys. You do not enter any Stripe keys; you only choose currencies, invoice terms and the collection model. Seller payouts are sent by the platform through Stripe transfers.
• Tenant Owned: your own Stripe account is used for payments and webhooks, with optional Stripe Connect for seller payouts. You are responsible for your keys, rotating them, and your webhook endpoints. Seller payouts are paid by you and recorded in Babylon with Mark Paid Manually.
• Hybrid: a mix of platform infrastructure and your own keys. Which leg uses which account is set by your contract with Babylon, so agree this with Hammerd support before choosing it. You enter your own keys, and seller payouts are sent through Stripe transfers.
• Offline Only: no online card capture. Orders are recorded and settled by hand (bank transfer, payment in the room and so on). Stripe settings are not used, and seller payouts are recorded with Mark Paid Manually.

In Tenant Owned, Hybrid and Offline Only modes, staff whose role can record offline payments (by default, Admin) can also record a payment received outside Babylon against an order's invoice. See Orders, settlements and payouts.

When you choose Babylon Managed or Offline Only, the page shows a short note in place of the Stripe section explaining that your own Stripe keys and webhooks are not used in that mode.

If your sales operating model is Model 3: Tenant seller-of-record, payouts on those sales are always manual, whatever the payment mode.

Payment Collection Model

Separate from the payment mode, this sets how much of the buyer's total Babylon collects. The default is full collect.

• Full collect (platform collects full buyer total): the buyer pays the whole amount (item price, buyer's premium, tax and shipping) through checkout.
• Deposit only (platform collects fees deposit; balance paid off-platform): at checkout Babylon collects only the buyer's premium plus any tax on it. The rest is paid by the buyer directly to the seller, off platform, and the seller confirms it before fulfilment. No seller commission is recorded on these orders, and refunds through Babylon are limited to the deposit collected.

Supported Currencies (ISO 4217)

The currencies you accept, as three-letter ISO codes such as GBP, USD or EUR. At least one is required and you can list up to 10. Codes are saved in capitals and duplicates are removed. Babylon uses this list to check the currency chosen for an invoice or payment.

Invoice Due (days)

How many days a buyer has to pay a newly issued invoice. The default, 0, means payment is due immediately. Unpaid orders whose payment due date has passed are shown as overdue payments on Post-Sale → Overview.

Stripe & Payouts

This section only appears when Payment Mode is Tenant Owned or Hybrid. Change the mode first and the section appears straight away, before you save.

Go to Settings → Business Settings → Commerce → Stripe & Payouts.

Active Stripe Environment

Chooses which of your two key sets checkout and card entry use: Test or Live. You can store both sets at once; this setting picks the one in use.

Switching between them is deliberately guarded. When you save with a different environment selected, Babylon stops and asks you to confirm before anything is saved:

• Switching to Live shows "Switch this tenant to live Stripe keys". It explains that buyers will be charged real money from the next transaction, that card details captured under the test keys do not carry over, and that any charge taken afterwards is genuine and must be refunded through Stripe. Confirm with Go live and save.
• Switching to Test shows "Switch this tenant to test Stripe keys". It explains that real cards will be declined and your storefront will stop taking money for as long as test is selected; live payments already taken are unaffected. Confirm with Switch to test and save.

If you cancel the prompt, nothing on the page is saved.

Enable Stripe Connect

Off by default. When on, seller payouts can use Stripe Connect, and checkout separates your platform fee for sellers who have a connected Stripe account. Sellers without a connected account are unaffected at checkout. Whatever this setting, a payout to a seller with no connected Stripe account waits in Pending Account until they finish Stripe onboarding.

Stripe (Test) and Stripe (Live)

Each environment has its own set of fields:

• Publishable Key (Test) / Publishable Key (Live): starts pk_test_... or pk_live_.... Publishable keys are safe to display, so the saved value is shown.
• Secret Key (Test) / Secret Key (Live): starts sk_test_... or sk_live_....
• Webhook Secret (Test) / Webhook Secret (Live): the signing secret for your payments webhook endpoint, starting whsec_....
• Billing Webhook Secret (Test) / Billing Webhook Secret (Live): optional. The signing secret for a separate billing webhook endpoint. If you leave it unset, billing webhooks are checked against the payments webhook secret.
• Identity (KYC) Webhook Secret (Test) / Identity (KYC) Webhook Secret (Live): the signing secret for Stripe Identity deliveries. Until it is set, identity verification events sent to your webhook endpoint are rejected. See Identity verification.

For how to create the webhook endpoints and where to find each signing secret, follow Stripe webhooks.

How saved secrets behave

Secret fields never show a saved value. Instead the help text under each field reads, for example, "Configured (••••1a2b). Leave blank to keep existing." with the last four characters of what is stored, or "Not configured" if nothing is saved.

• To keep a stored value, leave the field blank (or leave the masked value as it is).
• To replace a value, paste the new one and save.
• Blank fields never clear a stored key or secret, and there is no control on this page to remove one. If you need a key removed rather than replaced, contact Hammerd support.

Payout Rules (JSON)

A small JSON object that adds a holding period to seller payouts. The only setting Babylon currently reads is hold_days:

{"hold_days": 7}

• hold_days (a whole number of days): when above 0, every new payout is created with status Held and a hold end date that many days ahead (a payout still waiting in Pending Account keeps that status instead). The same hold is applied when a payout is recalculated after a dispute is resolved. In the current version the payout is not released automatically when that date passes: someone whose role can execute payouts (Admin or Finance Manager) must open it and click Mark Releasable. Read the payout statuses in Orders, settlements and payouts before turning this on.
• Leave the field empty, or enter {}, for no hold.
• Any other key is ignored. The example in the on-screen help text also shows min_days_after_delivery, but that key has no effect at present.
• The value must be valid JSON describing an object. If it is not, the save stops with "Payout rules must be valid JSON.". Some sections of the page may already have been saved before the error, so fix the JSON and save again.

The field is only visible in Tenant Owned or Hybrid mode, but a value you saved earlier stays in force if you later switch mode. Clear it before switching if you no longer want the hold. See Orders, settlements and payouts for how held and releasable payouts are handled.

Fixed Price

Go to Settings → Business Settings → Commerce → Fixed Price. These settings apply to Buy Now style listings and offers on them. See Auctions, offers and deal rooms.

• Enable Fixed Price Listings: on by default. Allows fixed price listings on your marketplace.
• Enable Offers on Fixed Price: on by default. Lets buyers make offers on fixed price listings.
• Enable Multi-Unit Fixed Price: on by default. Allows a fixed price listing to sell more than one unit.
• Reservation Hold (minutes): default 15, minimum 1. How long an item is held for a buyer at checkout after they click Buy Now or have an offer accepted. If they do not pay in time, the item is released.
• Offer TTL (minutes): default 60, minimum 5. Pending offers expire automatically after this long.
• Dispute Window (days): default 7, minimum 1. The default window for raising a dispute on a fixed price order. See Disputes, refunds and exceptions.

Troubleshooting

The Stripe & Payouts section is missing. Your Payment Mode is Babylon Managed or Offline Only. Choose Tenant Owned or Hybrid to see it.

I saved but got a confirmation prompt instead. You changed Active Stripe Environment. Confirm the switch to save, or change it back and save again.

Buyers' cards are being declined. Check Active Stripe Environment. If it is set to Test, real cards will not work.

Webhook events are failing signature checks. Make sure the secret you pasted matches the endpoint and environment in Stripe, and that you saved it in the matching Stripe (Test) or Stripe (Live) fieldset. See Stripe webhooks.

The save failed with a message about currencies. Each code must be exactly three letters, and you can list at most 10.