Payments

Overview

Bronjoy supports collecting payments when clients book appointments, processed through Stripe Checkout — clients are redirected to Stripe's hosted payment page, and Bronjoy handles the rest automatically via webhooks. You don't need your own Stripe account; you just enable payments and set your policy.

For how to turn it on, see Stripe Integration.

Payment Settings

Each organization configures its own payment policy — whether payment is required, deposit vs. full payment, refund behavior, and reminders.

View current settings

GET /api/org/payment-settings
Authorization: Bearer your-owner-token
X-Organization-ID: 1

Update your policy

POST /api/org/payment-settings
Authorization: Bearer your-owner-token
X-Organization-ID: 1
Content-Type: application/json

{
  "provider": "stripe",
  "is_enabled": true,
  "prepay_policy": "partial",
  "prepay_percentage": 30,
  "refund_on_cancellation": true,
  "refund_deadline_hours": 24,
  "auto_remind_unpaid": true,
  "remind_after_minutes": 60
}

See Stripe Integration for the full field reference.

Toggle payments on/off

POST /api/org/payment-settings/{paymentSetting}/toggle

How Payments Work

At booking time

When a client books a service that requires payment:

1. Client selects a service and time slot
2. Client submits the booking
3. Bronjoy creates the appointment in Pending status
4. A Stripe Checkout Session is created
5. Client is redirected to Stripe to pay
6. After payment, Stripe sends a webhook
7. Bronjoy confirms the appointment and records the transaction

Payment types

Configure per-service:

• prepay_required: true — enables payment at booking
• prepay_amount: 50000 — deposit amount (omit for full payment)

Payment states

Managing Transactions

View transactions

GET /api/org/transactions
Authorization: Bearer your-owner-token

Filter by date, status, or service:

GET /api/org/transactions?start_date=2026-03-01&end_date=2026-03-31&status=completed

Transaction summary

GET /api/org/transactions/summary

Returns totals for completed, refunded, and pending transactions in the given period.

Export data

GET /api/org/transactions/export?start_date=2026-03-01&end_date=2026-03-31

Refunds

Process a refund for a completed transaction:

POST /api/org/payments/{transaction}/refund
Authorization: Bearer your-owner-token

The refund is processed through Stripe. The transaction status changes to Refunded and the client is notified.

When to refund

• Client cancels within policy — if the cancellation window hasn't passed, refund the full amount
• Service not delivered — refund proactively to maintain trust
• Partial dissatisfaction — consider a partial refund (done directly in Stripe Dashboard)

Payment from the Client Side

Clients interact with payments through these endpoints:

# Check if payment is required
GET /api/client/payments/appointments/{appointment}/requirement

# Initiate payment
POST /api/client/payments/appointments/{appointment}/pay

# View payment history
GET /api/client/payments/appointments/{appointment}/transactions

# Check transaction status
GET /api/client/payments/transactions/{transaction}

Best Practices

• Test in Stripe test mode first — use pk_test_ / sk_test_ keys until you're confident
• Set reasonable deposit amounts — too high deters bookings; too low doesn't protect against no-shows. 20–50% of the service price is typical
• Enable payment only for high no-show services — not every service needs prepayment. Enable it selectively for services where no-shows cost you time and money
• Review transactions weekly — catch failed payments and expired sessions early
• Process refunds promptly — delayed refunds cause chargebacks and damage trust
• Don't configure Click.uz or Payme.uz — these payment providers are paused until legal entity registration is completed