Payment types module — JetSetGo MCP reference

The paymenttypes module defines the payment methods a JetSetGo tenant offers — generic categories such as card, cash or bank-transfer style types rather than specific providers. Each payment type carries a surcharge percentage, optional linkage to a payment gateway record, flags controlling point-of-sale and on-account (invoiced-later) usage, and a sort order for display. Bookings reference a payment type when recording how they were or will be paid.

What the operator uses it for

Operators shape the payment options presented across booking and checkout surfaces: naming each type, categorising it, setting any surcharge applied to its use, and deciding where it may be used — at the point of sale, on account against a later invoice, or both. Sort keys control the order types appear in selection lists.

A second concern is gateway surcharge management. Payment gateway records are maintained separately from payment types and hold their own surcharge percentage and a type classification. Operators adjust these surcharges independently of the payment types that link to them.

Where it sits

This is upstream reference data: checkout and booking flows read payment types to render choices and apply surcharges, and bookings store which type was used. Gateway records expose capability-level metadata only — name, surcharge and type; no provider connection details or credentials are managed or exposed here. Tenant-wide defaults such as regional formats live in the settings module.

Key concepts

Payment type — a named method of payment (a category, not a provider) that bookings can reference.
Surcharge percent — an optional percentage (0–100) added when the payment type is used.
Gateway linkage — an optional association from a payment type to a payment gateway record.
Payment gateway — a separate record holding a name, a type classification and its own surcharge percentage.
POS flag — whether the type may be used at the point of sale.
On-account flag — whether the type may be used on account, deferring collection to invoicing.
Sort key — numeric ordering used by selection lists.
Soft delete — deletion marks a type inactive; historical bookings keep their reference.

Tools

Tool	Class	Purpose
`paymenttypes_list`	Read	List non-deleted payment types ordered by sort key, joined with gateway records when tracked.
`paymenttypes_get`	Read	Fetch one payment type by id, same join behaviour.
`paymenttypes_gateways_list`	Read	List payment gateways (name, surcharge percent, type).
`paymenttypes_save`	Guarded write	Create or update a payment type; create requires a name; updates accept any field subset.
`paymenttypes_delete`	Guarded write	Soft-delete a payment type (reversible).
`paymenttypes_gateway_surcharge`	Guarded write	Update one gateway's surcharge percentage; non-destructive and idempotent.

Rules worth knowing

Validation is minimal but enforced: a name is required on creation, and the surcharge must be numeric between 0 and 100. Updates accept any subset of fields.
Deletion is always soft: deleted rows drop out of listings but remain referenced safely by historical bookings.
Gateway identity is a natural string key: gateways are addressed by name rather than a numeric id, so surcharge updates target the exact gateway name returned by the list tool.
Gateway data is capability metadata only: names, types and surcharge percentages. The module neither reads nor writes provider credentials or integration configuration.
Reads degrade gracefully per tenant: the gateway join on payment-type reads is included only where the underlying relationship is tracked; otherwise the tools fall back to flat ids instead of failing.
Surcharge updates are idempotent: setting the same value repeatedly is safe and never destructive.
Two surcharge layers exist: the payment type's own surcharge and its linked gateway's surcharge are independent values; changing one does not change the other.

Payment terms — governs when on-account use of a payment type is invoiced and settled.
Settings — owns tenant-wide configuration consumed alongside payment options at checkout.
Bookings — record which payment type was used for each booking.
Invoices — receive on-account payments deferred past the booking itself.