Billing and payments

Comprehensive documentation for billing and payments in KilatKoding, including checkout, orders, subscriptions, and provider webhooks.

This feature connects pricing in the UI to real transactions in the backend. It covers checkout, order pages, subscription management, and payment provider webhooks.

What this feature includes

• /checkout
• /order/[id]
• /dashboard/billing
• POST /api/payments
• POST /api/subscription
• POST /api/webhooks/midtrans
• POST /api/webhooks/doku

Related routes and endpoints

Route or endpoint	Type	Purpose
/checkout	Public page	Starts checkout from pricing or upgrade CTA
/order/[id]	Public page	Shows order status and transaction result
/dashboard/billing	Dashboard page	Lets users manage plan changes, cancellation, and resume
POST /api/payments	API mutation	Creates a payment session or pending payment
POST /api/subscription	API mutation	Cancels or resumes a subscription
GET /payment/callback	Callback route	Redirects back to order or billing after a payment callback
POST /api/webhooks/midtrans	Webhook	Verifies and processes Midtrans events
POST /api/webhooks/doku	Webhook	Verifies and processes Doku events

Main dependencies

Item	Required?	Notes
NEXT_PUBLIC_ENABLE_PAYMENTS=true	Yes	Enables the billing path
Auth enabled	Yes	Users need accounts for billing flows
PAYMENT_PROVIDER	Yes	midtrans or doku
Provider credentials	Yes	Must match the selected provider
SUPABASE_SERVICE_ROLE_KEY	Yes for many writes	Used for payment writes, audit logs, and subscription updates

Main files and configuration

Area	Main file
Plan catalog	config/subscriptions.ts
Pricing copy	components/sections/*
Payment route	app/api/payments/route.ts or equivalent
Subscription action	app/api/subscription/route.ts or equivalent
Webhooks	app/api/webhooks/*

What teams usually customize

• plan names and benefits,
• pricing,
• upgrade CTA paths,
• checkout copy,
• success and failure messaging,
• cancel and resume behavior,
• order page messaging.

When this feature is disabled

Payments are usually turned off when:

• the product does not sell access publicly,
• the product is only a private member portal,
• launch is still focused on waitlist or early validation.

When disabled, clean up:

• checkout pricing,
• upgrade CTA copy,
• any public promise about subscriptions,
• dashboard billing entry points that are no longer relevant.

Verification checklist

1. One sandbox payment can be created successfully.
2. The order page shows the correct state.
3. Webhooks arrive at the correct route.
4. Subscription state changes correctly.
5. Cancel and resume work in a test account.
6. Admin users can see the relevant payment and event data.

If you are still choosing a provider or filling env values, continue to Services setup and Environment variables.