# Let the buyer choose how to pay

Building with an AI agent? Start at https://docs.payme.io/agents.md

## Prerequisites

- The seller's seller_payme_id (MPL)
- Apple Pay, Google Pay or Bit turned on for the seller, to offer more than cards
- A public HTTPS URL for sale_callback_url

## Related

- [Create a multi-method checkout sale](/payments/hosted-payment-page/post-generate-sale-2)
- [Template sales (one link, many payments)](/accepting-payments/checkout-and-in-person/multi-payment-page)
- [Accept Apple Pay](/accepting-payments/payment-methods/apple-pay)
- [Accept Google Pay](/accepting-payments/payment-methods/google-pay)
- [Accept Bit payments](/accepting-payments/payment-methods/bit)
- [Enable payment methods and services for your sellers](/marketplaces-and-platforms/seller-onboarding/enable-services)
- [Callbacks](/payments/getting-started/callbacks)
- [List transactions](/payments/query-apis/post-get-transactions)
- [Refund a sale](/payments/post-sale-actions/post-refund-sale)

With `sale_payment_method: multi`, PayMe's payment page offers every payment method that is turned on for the seller, and the buyer picks one: a card, Apple Pay, Google Pay or Bit. You create one sale and get one result, whichever method the buyer used.

Use `multi` when you don't want to choose the method for the buyer. To offer a single method, send that method instead, for example `apple-pay` or `bit`.

## Create the sale

Call [`generate-sale`](/payments/hosted-payment-page/post-generate-sale-2) from your server with `sale_payment_method: multi`. The field defaults to `credit-card`, so a request without it gets a card-only page.

`POST https://sandbox.payme.io/api/generate-sale` (production: `https://live.payme.io/api/generate-sale`)

```json
{
  "seller_payme_id": "MPLDEMO-MPLDEMO-MPLDEMO-1234567",
  "sale_payment_method": "multi",
  "sale_price": 1000,
  "currency": "ILS",
  "product_name": "Smartphone",
  "transaction_id": "order-1001",
  "installments": "1",
  "sale_callback_url": "https://your-server.example.com/payme/callback",
  "sale_return_url": "https://your-site.example.com/payment/success",
  "sale_name": "First Last",
  "sale_email": "buyer@example.com",
  "sale_mobile": "+972500000040",
  "language": "en"
}
```

```json
{
  "status_code": 0,
  "session": "AtsJ0as5",
  "sale_url": "https://sandbox.payme.io/sale/generate/SALE1700-000000AA-EXAMPLE1-SALE0001",
  "payme_sale_id": "SALE1700-000000AA-EXAMPLE1-SALE0001",
  "payme_sale_code": 12345678,
  "price": 1000,
  "transaction_id": "order-1001",
  "currency": "ILS",
  "sale_payment_method": "multi"
}
```

Show `sale_url` to the buyer in an iframe or a redirect. Store `payme_sale_id`: refunds and queries use it.

- Partners also send `payme_client_key`. See [Authentication](/payments/getting-started/authentication).
- `sale_name`, `sale_email` and `sale_mobile` pre-fill the buyer's details on the page, for the card form and for Bit.
- Creating a `multi` sale doesn't check which methods the seller has. A seller with no other method turned on gets a page with the card form only.
- Every other field, and the `sale_url` validity rules, are on [Create a multi-method checkout sale](/payments/hosted-payment-page/post-generate-sale-2).

## Which methods the buyer sees

The card form is always on the page. Apple Pay, Google Pay and Bit appear only when every rule below allows them. PayMe applies the rules each time the page opens.

### 1. The seller has the method turned on

A method appears only when the seller's service for it is active. A seller installs Apple Pay, Google Pay or Bit from the dashboard app store (חנות אפליקציות); a partner turns them on with `vas-enable`. See [Enable payment methods and services for your sellers](/marketplaces-and-platforms/seller-onboarding/enable-services). When a service is turned off, its button no longer appears.

### 2. The installments allow a single payment

Apple Pay, Google Pay and Bit pay in one payment, so a fixed number of installments hides them:

| `installments` you send | Methods on the page |
|---|---|
| `1` (default) or `0` | Card, and every active wallet and Bit. One payment. |
| `2`–`12` (a fixed number) | Card only |
| `102`–`112` (the buyer chooses up to the last two digits) | Card, and every active wallet and Bit. A card buyer chooses the number of payments; a buyer who pays with Apple Pay, Google Pay or Bit pays in one payment, and the Bit option says so. |

More than one installment is ILS only (error `312`).

### 3. The buyer's device can pay with the wallet

PayMe shows a wallet button only when the buyer's browser can use it:

- **Apple Pay** appears when the browser supports Apple Pay and it is set up on the device, for example Safari on an iPhone with Apple Pay set up. See [Accept Apple Pay](/accepting-payments/payment-methods/apple-pay) for the supported devices.
- **Google Pay** appears when Google Pay reports that the buyer can pay in this browser. See [Accept Google Pay](/accepting-payments/payment-methods/google-pay).

When the check fails, the button is left out and the buyer still sees the other methods. A test from Chrome on Windows, for example, shows no Apple Pay.

### 4. Saving the card (`capture_buyer`) limits the methods

With `capture_buyer`, only methods that can save a token for later charges are offered: the card, and Apple Pay when PayMe has set up the seller's Apple Pay service for saved tokens. Google Pay and Bit are left out.

### 5. Bit pays in ILS only

Bit charges in ILS only, so a buyer can complete a Bit payment only on an ILS sale. See [Accept Bit payments](/accepting-payments/payment-methods/bit).

### Not on this page

PayPal, bank transfers, Israeli direct debit and the other methods on [Available Payment Methods](/payments/wallets-apms) aren't offered on a `multi` page. Create the sale with that method's `sale_payment_method` instead.



## What the buyer does

The Apple Pay and Google Pay buttons come first, then the card form and Bit. When both the card and Bit are offered, each is a section the buyer opens. When the card is the only method, the page opens straight on the card form.

- **Card:** the buyer fills in the card form. 3D Secure runs as on any card sale.
- **Apple Pay or Google Pay:** the buyer taps the button and approves the payment in the wallet.
- **Bit:** the buyer confirms their details, then scans the QR code (on a computer) or opens the Bit app (on a phone), and approves the payment in Bit.

If the buyer opens a Bit request and then pays another way, PayMe cancels the open Bit request, so the sale can't be paid twice. A failed attempt doesn't close the page: the buyer can try again, with the same method or another one. After a successful payment, PayMe redirects the buyer to `sale_return_url`, if you sent it.



## Callbacks

A `multi` sale sends the same callbacks as any sale, to `sale_callback_url`:

| `notify_type` | When |
|---|---|
| `sale-complete` | The buyer paid, with any method |
| `sale-authorized` | With `sale_type: authorize`: the payment was authorized and waits for [capture](/accepting-payments/capture-and-saved-cards/capture-sale) |
| `sale-failure` | An attempt failed. Sent once per failed attempt; the sale can still complete afterwards |
| `refund` | The sale was refunded |
| `sale-create` | The sale was created. Only when you send `sale_send_creation_callback: true` |

In `sale-complete`, `sale-authorized` and `sale-failure`, `sale_payment_method` is the method of that attempt: `credit-card`, `apple-pay`, `google-pay` or `bit`, never `multi`. After an Apple Pay, Google Pay or Bit payment, `installments` is `1`.

The fields, the signature and the delivery rules are on [Callbacks](/payments/getting-started/callbacks). Before you fulfil the order, confirm the sale's status and amount with [`get-sales`](/payments/query-apis/post-get-sales).



## Find out how the buyer paid

| Where | What you see |
|---|---|
| Callbacks about a payment attempt | `sale_payment_method`: the method of that attempt |
| [`get-sales`](/payments/query-apis/post-get-sales) | `sale_payment_method` stays `multi` |
| [`get-transactions`](/payments/query-apis/post-get-transactions) | `transaction_payment_method`: the method used on each transaction. You can also filter on it. |

## Refunds

Refund a `multi` sale with [`refund-sale`](/payments/post-sale-actions/post-refund-sale), as any other sale. The money goes back to the method the buyer paid with.

## `multi` and template sales

The two are easy to confuse. The guide [Template sales](/accepting-payments/checkout-and-in-person/multi-payment-page) was formerly titled "Multi Payment Page"; it is about one link that many buyers pay, not about choosing a payment method.

| | `multi` | Template sale |
|---|---|---|
| You send | `sale_payment_method: multi` | `sale_type: template` |
| It solves | One buyer chooses how to pay | Many buyers pay the same link |
| Sales | One sale | A new sale for each payment |

You can combine them: a template sale with `sale_payment_method: multi` lets each buyer of the shared link choose how to pay.



## Test in the sandbox

- Pay with the cards on [Test Cards and Payment Methods](/payments/getting-started/test-cards-and-payment-methods).
- The Apple Pay and Google Pay buttons appear only on a device and browser that support them (rule 3).
- To test Bit, see [Accept Bit payments](/accepting-payments/payment-methods/bit).