Payments
Gett offers flexible payment options to match your integration approach. Choose the path that best fits your platform's needs.
| Approach | Description | Best For |
|---|---|---|
| Automatic (Marketfront SDK-only) | Gett handles payment collection | Don't have existing payment data |
| Card-on-File | Leverage your existing saved customer cards | Have existing payment data, want to maximize conversion. Required for Marketfront API and Marketfront AI. |
What is Card-on-File?
Card-on-File allows you to use payment methods your customers have already saved with your platform. Instead of requiring users to re-enter their card details, Gett securely proxies the payment data to the restaurant's payment processor.
You Likely Already Have Card-on-File Capability
"Card-on-file" doesn't mean storing raw credit card numbers. If your platform uses a payment processor like Stripe, Braintree, Square, Adyen, or any other major provider, you already have tokenized cards that qualify for Card-on-File integration.
When customers save their payment method on your platform, your processor stores the sensitive card data and gives you a secure token. Gett works with all major payment processors to securely translate these tokens—your existing payment infrastructure is all you need.
Why Card-on-File?
| Benefit | Description |
|---|---|
| Higher Conversion | Users complete checkout without friction—no new payment entry required |
| Seamless User Experience | Users existing payment methods are automatically available |
| Trust | Users don't need to share payment info with a new system |
How It Works
When a consumer places an order using Card-on-File, Gett acts as a secure bridge between your payment infrastructure and the restaurant's:
- Your platform provides a token reference — The
paymentTokenfrom your existing payment processor - Gett securely retrieves the card data — Using pre-configured, encrypted channels to your processor
- Gett re-tokenizes for the restaurant — The card is tokenized with the restaurant's payment processor
- The restaurant charges using their token — Payment is processed through the restaurant's own infrastructure
This token-to-token interchange ensures:
- Your systems never handle raw card data
- The restaurant receives a token compatible with their processor
- All sensitive data flows through PCI Level 1 compliant infrastructure
PCI Compliance
Gett maintains PCI DSS Level 1 compliance, the highest level of payment security certification. By integrating with Gett, your platform benefits from our secure infrastructure without the compliance burden.
Your platform stays out of PCI scope — you only pass token references, never sensitive card data.
Card-on-File Implementation
Card-on-File works slightly differently depending on whether you're using the Marketfront SDK or the Marketfront API.
| Integration | Session Creation | Order Placement |
|---|---|---|
| Marketfront SDK | Pass payment method metadata (for UI display) | Reference payment by paymentToken |
| Marketfront API | N/A | Reference payment by paymentToken |
| Marketfront AI | N/A | Reference payment by paymentToken |
Order Amounts
Every order request and response includes an amounts object that breaks down the full monetary value of the order. Each field carries a real, non-zero value when applicable.
Fields
| Field | Type | Description |
|---|---|---|
subTotal | number | Item cost before fees, taxes, or adjustments |
fees | number | Service and booking fees |
feesDetails | AmountDetail[] | Per-fee breakdown (sum must equal fees) |
taxes | number | Total tax, including line-item-specific taxes |
taxesDetails | AmountDetail[] | Per-tax breakdown (sum must equal taxes) |
promotions | number | Total discounts applied — represented as a positive value, subtracted from total |
promotionsDetails | AmountDetail[] | Per-promotion breakdown |
tip | number | Tip passed through in full to the merchant |
tipDescription | string | Optional label for tip distribution (e.g., "Staff: $5, Driver: $5") |
adjustments | number | Manual post-placement corrections; can be negative |
adjustmentsDetails | AmountDetail[] | Per-adjustment breakdown |
total | number | Final charge amount |
Composition Formula
Code
Requests where these fields don't sum to total (within $0.01) are rejected with 400.
Data Sources
| Source | Fields |
|---|---|
| Computed by Gett from your cart | subTotal, tip |
| Provided by the merchant | fees, taxes |
Tip Flow
Partners can include a customer tip when calling validateOrder or placeOrder by setting amounts.tip. Gett passes the full tip amount to the merchant without deduction. The optional tipDescription field lets you describe how the tip should be distributed (e.g., between staff and delivery driver).
Not all stores accept tips — check the acceptsTipsOnDelivery and acceptsTipsOnPickup flags on the store object before presenting a tip prompt.
When Amounts Are Set
| Stage | Behavior |
|---|---|
validateOrder request | Partner provides tip (optional); all other fields may be omitted |
validateOrder response | Server returns the full computed breakdown — use this to display a pricing preview |
placeOrder request | Include the validated amounts from the previous step |
placeOrder response | Provider returns the authoritative post-placement breakdown; this is persisted and locked |
Example
Code
For the full Amounts schema, see the API reference. For how amounts flow through the order pipeline, see the Order Lifecycle guide.
Configuration & Setup
Card-on-File interchange requires a one-time configuration between your platform and Gett. This configuration establishes the secure channel for payment data retrieval.
Contact Your Gett Representative
To enable Card-on-File for your integration, contact your Gett representative. Our team will work with you to configure secure payment interchange for your specific payment processor and architecture.
Next Steps
- Sessions — Session creation with payment methods
- Order Lifecycle — Order flow and state machine
- Schemas — Type definitions and data models