Core payment service
Use the server-only core when the application owns framework composition and payment stores.
Packages: @gj-kit/toss-payments
Build a Toss payment service
Choose the smallest payment boundary first, then add Nest dependency injection or PostgreSQL stores only when the host application needs them.
Choose the smallest fit
Section titled “Choose the smallest fit”NestJS payment service
Add the Nest package for typed provider registration and raw-body webhook handling.
Packages: @gj-kit/toss-payments, @gj-kit/toss-payments-nestjs
PostgreSQL-backed payment service
Add PostgreSQL stores for the shipped migration and encrypted persistence implementation.
Packages: @gj-kit/toss-payments, @gj-kit/toss-payments-postgresql
Composition boundary
Section titled “Composition boundary”This guide explains @gj-kit/toss-payments, @gj-kit/toss-payments-nestjs, @gj-kit/toss-payments-postgresql together, but it does not create an installation dependency unless the package relationship table says so.
1. Start with verification
Section titled “1. Start with verification”Create the core kit with the order and payment boundaries the server actually owns.
2. Add a host adapter only when needed
Section titled “2. Add a host adapter only when needed”Nest DI and PostgreSQL stores are extension choices, not prerequisites for a core integration.
3. Keep secrets and policy in the application
Section titled “3. Keep secrets and policy in the application”Key custody, refund policy, and application audit decisions remain outside the packages.