# 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 solution.

:::tip{title="You Likely Already Have Card-on-File Capability"}
**"Card-on-file" doesn't mean storing raw credit card numbers.** If your platform already lets customers save a payment method, you almost certainly have tokenized cards that qualify for Card-on-File integration.

When customers save their payment method on your platform, your payment solution stores the sensitive card data and gives you a secure token. Gett works with your existing payment solution 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:

1. **Your platform provides a token reference** — The `paymentToken` from your existing payment solution
2. **Gett securely retrieves the card data** — Using pre-configured, encrypted channels to your payment solution
3. **Gett re-tokenizes for the restaurant** — The card is tokenized with the restaurant's payment solution
4. **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 payment solution
- 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

All monetary amount fields are **decimal strings** (e.g. `"24.50"`), never bare JSON numbers. See the [Money & amounts](/distribution-partners/marketfront-api/conventions#money--amounts) conventions for the rationale and precision rules.

| Field | Type | Description |
|-------|------|-------------|
| `currency` | string | ISO 4217 currency code, e.g. `USD` |
| `subTotal` | string (decimal) | Item cost before fees, taxes, or adjustments |
| `fees` | string (decimal) | Service and booking fees |
| `feesDetails` | AmountDetail[] | Per-fee breakdown (sum must equal `fees`) |
| `taxes` | string (decimal) | Total tax, including line-item-specific taxes |
| `taxesDetails` | AmountDetail[] | Per-tax breakdown (sum must equal `taxes`) |
| `promotions` | string (decimal) | Total discounts applied — represented as a **positive** value, subtracted from total |
| `promotionsDetails` | AmountDetail[] | Per-promotion breakdown |
| `tip` | string (decimal) | Tip passed through in full to the merchant |
| `tipDetails` | AmountDetail[] | Per-recipient tip breakdown (sum must equal `tip`) |
| `adjustments` | string (decimal) | Manual post-placement corrections; can be negative |
| `adjustmentsDetails` | AmountDetail[] | Per-adjustment breakdown |
| `total` | string (decimal) | Final charge amount |

### Composition Formula

```
total = subTotal + fees - promotions + taxes + adjustments + tip
```

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 `tipDetails` array lets you itemize how the tip is distributed (e.g. between staff and delivery driver) — when non-empty, its amounts must sum to `tip`, and it is passed through to the merchant in full. Omit it when the tip isn't itemized.

Not all stores accept tips — check the `acceptsDeliveryTips` and `acceptsPickupTips` flags on the store's `options` 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

```json
{
  "amounts": {
    "currency": "USD",
    "subTotal": "24.50",
    "fees": "2.99",
    "feesDetails": [{ "amount": "2.99", "description": "Service fee" }],
    "taxes": "2.20",
    "taxesDetails": [{ "amount": "2.20", "description": "Sales tax" }],
    "promotions": "0",
    "tip": "4.00",
    "adjustments": "0",
    "total": "33.69"
  }
}
```

For the full `Amounts` schema, see the [API reference](/api/marketfront/~schemas/Amounts). For how amounts flow through the order pipeline, see the [Order Lifecycle](/distribution-partners/marketfront-api/guides/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, and is what makes the `paymentToken` you send on `placeOrder` resolvable.

:::info{title="Contact Your Gett Representative"}
To enable Card-on-File for your integration, contact your Gett representative. Our team will work with you to integrate your existing payment solution — whatever it is — and configure the secure payment interchange for your architecture.
:::



---

## Next Steps

- [Sessions](/distribution-partners/marketfront-sdk/guides/sessions) — Session creation with payment methods
- [Order Lifecycle](/distribution-partners/marketfront-api/guides/order-lifecycle) — Order flow and state machine
- [Schemas](/api/marketfront/~schemas) — Type definitions and data models