PAR Pay

PAR Pay is the payment processor for PAR Ordering, and the one new integrations are configured with.

The flow itself is not PAR Pay specific — Make a Payment describes it, and it is the same for every processor. This page only covers what PAR Pay puts into that flow: what appears in additional_info, which actions you get, and what you have to send back when you create the order.

You will see PAR Pay under two payment_processor_type_id values, and occasionally a third:

What a payment initialization looks like

Everything below is the response to POST /api/cart/{cart_id}/payments/init. The envelope is always the same; only the last two fields vary.

For a saved card there is nothing for your client to do. Initialize, then create the order with the hash.

New card

The customer is paying with a card they have not saved, so the card details have to be collected by the processor rather than by you.

{
  "payment_init_hash": "032878b199f90e13e1bdce036e00f157",
  "payment_processor_type_id": 32,
  "amount": 1094,
  "expires_in": 1799,
  "additional_info": null,
  "actions": [
    {
      "type": "redirect",
      "url": "https://api-public-demo.menu.app/api/payment-processors/init_token?mt_application_id=683&mt_payment_processor_id=392&tokenType=1&template=card&isPayment=1&successUrl=…&failUrl=…&sessionId=309200223173329411640000363990&iframeUrl=https%3A%2F%2Fuatps48.aurusepay.com%2Fstoreservices%2Fecom%2Fgetiframe%3Fa%3D0369E34f1e9…"
    }
  ]
}

The URL is a page hosted by PAR Ordering that embeds the PAR Pay card form. Load it in a WebView or iFrame exactly as given — it carries a session that cannot be regenerated on your side.

When the customer submits the form you get a one-time token back in one of two ways:

A failure redirects to the fail URL with ?error=123456-ErrorMessage instead. The success and fail URLs are the ones already embedded in the action URL; PAR Pay can be configured to use endpoints of your own instead.

Send the token as payment_info.one_time_token when you create the order.

Apple Pay

{
  "payment_init_hash": "032878b199f90e13e1bdce036e00f157",
  "payment_processor_type_id": 32,
  "amount": 1094,
  "additional_info": {
    "merchant_id": "merchant.com.example.brand",
    "sessionId": "306805926262550654066895041517",
    "requestId": "82f86d9a-c772-42c6-9b92-f37438490b62",
    "amount": "10.94",
    "currency": "USD",
    "country": "US"
  },
  "actions": [
    {
      "type": "auth",
      "url": "https://api-public-demo.menu.app/api/payment-processors/auth-payment?mt_application_id=137&mt_payment_processor_id=56",
      "method": "POST"
    }
  ]
}

Open the Apple Pay sheet with these values. Apple then asks you to validate the merchant, which is what the auth action is for — post the validation URL to it as described in Make a Payment and hand the returned session_object to completeMerchantValidation().

Once the customer confirms, create the order with the Apple Pay payment data under payment_info.additional_info.get_session_token_request. PAR Ordering exchanges it for a token with PAR Pay; you do not call PAR Pay yourself.

Google Pay

{
  "payment_init_hash": "9d8416985b57de4b93d87f7f88ef11da",
  "payment_processor_type_id": 32,
  "amount": 1094,
  "additional_info": {
    "merchant_id": "784302",
    "gateway_merchant_id": "exampleGatewayMerchantId",
    "google_merchant_id": "12345678901234567890",
    "google_merchant_name": "Example Brand",
    "sessionId": "309100223174408561380000384143",
    "requestId": "0f6c2f8f-1f0c-4a2f-bb0e-6b0a3d4a1c22"
  }
}

There is no action to follow: open the Google Pay sheet with these values directly. gateway_merchant_id is the PAR Pay identifier you pass in the Google Pay tokenization specification; google_merchant_id and google_merchant_name are your Google Pay Business Console credentials.

Create the order with the Google Pay payment data under payment_info.additional_info.GetSessionTokenRequest.

The wallet keys differ in case between the two: Apple Pay is read from get_session_token_request and Google Pay from GetSessionTokenRequest. This is a quirk of the integration, not a typo in this guide.

Gift cards

A gift card the customer has not saved is validated against BIN ranges rather than a hosted form, because gift card numbers are not PCI-regulated and can be posted to us directly.

{
  "payment_init_hash": "9d8416985b57de4b93d87f7f88ef11da",
  "payment_processor_type_id": 35,
  "amount": 1094,
  "additional_info": {
    "bin_ranges": [
      { "range": { "from": "7000", "to": "9999" }, "pin_required": false, "refundable": true,  "rechargeable": true },
      { "range": { "from": "8307", "to": "9000" }, "pin_required": true,  "refundable": true,  "rechargeable": true },
      { "range": { "from": "200",  "to": "10001" }, "pin_required": false, "refundable": false, "rechargeable": false }
    ]
  }
}

Each range describes a rule for the cards whose leading digits fall inside it. The lower bound is at least three digits and there is no upper bound; the ranges are configured per brand.

Ranges can overlap, and a card that matches several is subject to all of them. In practice that means: if any matching range has pin_required: true, prompt for the PIN. refundable and rechargeable tell you whether to offer a refund back to the card and whether to offer a top-up.

Before charging it, you can confirm the card is valid with POST /customer-accounts/{customer_account_id}/gift-cards/check. It answers yes or no — it does not return a balance, and the card does not have to be saved first.

Create the order with payment_info.gift_card_number, plus payment_info.gift_card_code for the PIN where one is required.

A gift card rarely covers the whole basket, so this is the method most often used in a split payment.

Storing a PAR Pay payment method

Store Payment Method covers the full flow. Two things are worth knowing about PAR Pay specifically.

generate-tokens returns two processors, not one — the card processor (32) and the gift card processor (35) — and you have to follow the one that matches what the customer is saving. The card entry carries a redirect action to the same hosted form described above; the gift card entry carries bin_ranges instead.

The properties you post back differ by card type. For a card, send the one_time_token from the hosted form together with the token from generate-tokens. For a gift card, send gift_card_number and, where required, gift_card_code.

Once stored, the card is used like any other saved method: initialize with stored_payment_method_id, get no actions back, and create the order with just the hash.