# Accepting payments

Checkout can be used in several different ways to start accepting payments. These solutions share the same Checkout APIs and have a lot in common in terms of integration. You can find the integration paths on this page.

To generate checkout links via Checkout API, **you will need a Verifone Central user with one of the following roles** assigned to it:

* Merchant Supervisor
* Merchant Cashier

{% hint style="info" %}
Check the [Supported acquirers](/online-payments/supported-acquirers.md) documentation for more information on payment methods, card brands and acquirer details.
{% endhint %}

## Requirements <a href="#requirements" id="requirements"></a>

{% hint style="warning" %}
In order to start accepting eCommerce transactions, you will need to generate a [Secure Card Capture Key.](/online-payments/api-integration-methods-auth-and-endpoints/secure-card-capture-key.md)
{% endhint %}

<a href="/pages/7UXajXpQHSfbD0UuxCPc#sandbox-and-production-urls" class="button primary" data-icon="arrow-trend-down">Get your API endpoints here!</a>

## Hosted Payments Page (HPP) <a href="#hosted-payments-page-__0028hpp__0029" id="hosted-payments-page-__0028hpp__0029"></a>

With this approach, the shopper is redirected to a payment page hosted by Verifone to complete the payment. The shopping cart details, products and quantities can also be sent when doing HPP. Upon completion of the payment process, the shopper is redirected back to the URL of the merchant.&#x20;

{% hint style="info" %}
For Israel ABS, no card expiration check will be done.
{% endhint %}

## Iframe <a href="#iframe" id="iframe"></a>

Iframe allows for merchants to display a payment form component as part of their own website, without having to redirect the shopper. The form is still securely hosted by Verifone, so there is no additional PCI scope required for the merchant with this solution.

## Required fields <a href="#required-fields" id="required-fields"></a>

To configure [Checkout](/online-payments/checkout.md) for accepting payments, the following fields are required:

* `entity_id` - This value can be found in the Verifone Central portal or provided to you by a Verifone employee.

  <div data-gb-custom-block data-tag="hint" data-style="info" class="hint hint-info"><p>To obtain the <code>entity_id</code> value from Verifone Central, go to <em>Administration</em> > <em>Organizations</em> > [Organization] > <em>Organization ID</em> value.</p></div>

  \
  **Organization ID (Entity ID) in Verifone Central**

  <div data-with-frame="true"><figure><img src="/files/zBjcI08SE6rzr3jt9WmE" alt=""><figcaption></figcaption></figure></div>
* `currency_code`
* `amount`
* `configurations` - Object with one or more payment method configurations.

### Optional Checkout fields <a href="#optional-checkout-fields" id="optional-checkout-fields"></a>

* `customer` - ID of a customer created via the [Customer API](/api-reference/open-api-references/customer.md). A customer object can be created and attached to a checkout. The customer object can store relevant customer details. Some of these details might be required, depending on the payment method and/or authentication mechanisms (e.g., 3DS) used in the checkout.
* `expiry_time` - Expiry time of the checkout page. Defaults to 15 min from creation time. If a user tries to visit or use an expired checkout, an error will be shown. Maximum value is 30 days.
* `merchant_reference` - Reference provided by merchant to identify the checkout and the transaction initiated from it.
* `return_url` - URL belonging to the merchant website, where the customer would be redirected after the checkout has been completed. If this parameter is used, the customer will be redirected after spending 10 seconds on the payment confirmation page provided by Verifone in case of HPP and PAYMENT LINK transactions. For IFRAME transaction the redirect is performed right after the checkout page without passing through the payment confirmation page.
* `shop_url` - URL belonging to the merchant website, where the customer would be redirected in case of cancelled checkout.
* `i18n` - Language preferences for the page. Read [Localization](/online-payments/checkout/localization.md) for details.
* `interaction_type` - Indicates the type of integration. Allows for distinguishing payments accepted via different channels. If this parameter is not used, then the **createCheckout** API call will generate an HPP payment link.
  * **IFRAME** - For payments done as an Iframe integration.
  * **PAYMENT\_LINK** - For payments done through the Payment link feature in the merchant portal.
  * **HPP** - For payments done as Hosted Payments Page integration.

    <div data-gb-custom-block data-tag="hint" data-style="warning" class="hint hint-warning"><p>A privacy policy link in the HPP, IFRAME, PBL will be visible in case a PPC used is set up with Intercard acquirer.</p></div>
* `notification_methods` - This parameter is used for the PAYMENT\_LINK interaction type in order to specify the payment link delivery method.
  * email
  * sms
* `display_line_items` - Indicates whether line items should be displayed on the page. Defaults to true.
* `line_items` - List of shopping cart items, to be displayed on the page. Read [Line items](/online-payments/checkout/line-items.md) for details.
* `theme_id` - The parameter that was created within the theming API call that applies the customizations upon the checkout interface. Read [Theming](/online-payments/checkout/theming.md) for details.
* `receipt_type` - This parameter can be used to send different invoices to the customer.
  * INVOICE - requires line\_items to be specified in Israel&#x20;
  * FULL\_RECEIPT - requires line\_items to be specified in Israel
  * SIMPLE\_RECEIPT
  * INVOICE\_RECEIPT

## Creating a Checkout  <a href="#creating-a-checkout__00a0" id="creating-a-checkout__00a0"></a>

{% tabs %}
{% tab title="HPP" %}
Here is an example body creating a Checkout to be used as a Hosted Payments Page (default interaction\_type).

```json
{
  "amount": 74.55,
  "currency_code": "EUR",
  "entity_id": "{{entity_id}}",
  "configurations": {
    "{{payment_method}}": {
      // varies per payment_method
    }
  },
  "merchant_reference": "SNKRS-7001",
  "return_url": "https://merchantwebsite.com/order/1234",
  "interaction_type": "HPP" // also default value
}
```

The response for creating the Checkout will look like this.

```json
{
  "id": "38615263-ed67-4774-bddd-7407edc0b700",
  "url": "{{host}}/v2/checkout/38615263-ed67-4774-bddd-7407edc0b700/view"
}
```

{% endtab %}

{% tab title="Iframe" %}
Here is an example body for creating a Checkout to be used as Iframe.

```json
{
  "amount": 74.55,
  "currency_code": "EUR",
  "entity_id": "{{entity_id}}",
  "configurations": {
    "{{payment_method}}": {
      // varies per payment_method
    }
  },
  "merchant_reference": "SNKRS-7001",
  "return_url": "{{merchant_return_url}}",
  "interaction_type": "IFRAME"
}
```

The response for creating the checkout will look like this.

```json
{
  "id": "38615263-ed67-4774-bddd-7407edc0b700",
  "url": "{{host}}/v2/loader.js?checkoutId=38615263-ed67-4774-bddd-7407edc0b700"
}
```

{% endtab %}
{% endtabs %}

{% hint style="warning" %}
In the card field, a digits limitation has been set based on the active payment methods configured on the Payment Provider Contract.
{% endhint %}

## Displaying payment to the shopper  <a href="#displaying-payment-to-the-shopper" id="displaying-payment-to-the-shopper"></a>

{% tabs %}
{% tab title="HPP" %}
Redirect the shopper to the URL received as a response to creating a Checkout. They will see a ready-to-use payment page, displaying a summary of the payment details and the option to do a payment.
{% endtab %}

{% tab title="Iframe" %}

1. **Inject \<script> inline**

The URL from the response above can be used to place a \<script> tag as direct child of an HTML element where the Iframe should be displayed. This way, the script would automatically render the payment form in the same place of the HTML document as it is included.

```html
<html>
    <head>
    ...
    </head>
    <body>
    ...
    <div id="payment_form_container">
         <script defer src="{{host}}/v2/loader.js?checkoutId=38615263-ed67-4774-bddd-7407edc0b700"></script>
    </div>     
    </body>
</html>
```

2. **Inject script anywhere on the page**

The script can also be included anywhere in the merchant's HTML, as long as there is a `containerId` query parameter provided pointing to the ID of the parent HTML element in which the form should be displayed. So, if the desired parent element is a \<div> with id `payment_form_container`, this can look like:

```html
<html>
    <head>
    ...
        <script defer src="{{host}}/v2/loader.js?checkoutId=38615263-ed67-4774-bddd-7407edc0b700&containerId=payment_form_container"></script>  
    </head>
    <body>
    ...
    <div id="payment_form_container">
    </div>     
    </body>
</html>
```

{% endtab %}
{% endtabs %}

## Handling payment response <a href="#handling-payment-response" id="handling-payment-response"></a>

Whenever a payment is performed by a shopper through an HPP or IFRAME, it will result in a payment confirmation page.

If a `return_url`is specified by the merchant when creating a Checkout, the customer will be redirected to the `return_url` after the confirmation page. Depending on the result, the redirection would include `transaction_id` if a transaction is created and/or **error\_code** if an error has occurred.

The redirection URL for a successful transaction would look like this:

```json
https://merchantwebsite.com/order/1234?transaction_id={transaction_id}&checkout_id={checkout_id}
```

Both success and failure Checkout outcomes result in the customer being redirected to the confirmation page/ failed payment page. If a `return_url` is used, the customer will be redirected to that specific page afterwards.

{% hint style="info" %}
The `return_url` you have provided needs to link the Checkout ID with the order on your system, to be able to reliably handle the response.
{% endhint %}

**Example**:

* Customer places order and your system generates order ID `1234`
* You create a Checkout for this order and set the `return_url` to `https://merchantwebsite.com/order/1234`
* The API responds with `id` and `url`. You ensure that this `id` is linked to the `order_id` in your system, so that you can match them later.
* You redirect the customer to the `url`
* The customer completes the Checkout and is redirected to the `return_url` with query string parameters appended to it by Verifone. For a successful transaction, the final redirection URL would look like: <https://merchantwebsite.com/order/1234?transaction_id={transaction_id}&checkout_id={checkout_id}>
* Because your return URL uniquely identifies the `order_id`, you know which checkout belongs to the order
* To determine the outcome, you can read back the Checkout by calling the `GET /v2/checkout/{checkout_id}` using the `id` of the Checkout stored earlier and inspect the `events` field

{% hint style="info" %}
To ensure that the redirection request was not tampered with, always check that the `transaction_id` received as a query parameter in the redirection matches the `transaction_id` property of the retrieved Checkout. If those are not matching, this is an indication of either an incorrect integration, that the redirection to your `return_url` did not originate from Verifone, or the `transaction_id` was tampered with.
{% endhint %}

* You can now store the `transaction_id` value together with the order `1234` in your system to link the two together

## Read Checkout <a href="#read-checkout" id="read-checkout"></a>

To determine the outcome of the Checkout, the merchant should query the checkout by doing a Server-to-Server call to **GET /v2/checkout/{checkout\_id}**. In the response, they would find the `events` field.

**Successful** transaction response:

```json
[
  ...
  {
      "type": "TRANSACTION_SUCCESS",
      "id": "f2041250-4fc2-4b3a-bc94-651ba099541a",
      "timestamp": "2020-07-08T12:42:37.974Z",
      "details": {
         // varies per payment method
      }
  }
  ...
]
```

**Failed** transaction response:

```json
[
  ...
  {
      "type": "TRANSACTION_FAILED",
      "id": "f2041250-4fc2-4b3a-bc94-651ba099541a",
      "timestamp": "2020-07-08T12:42:37.974Z",
      "details": {
         // varies per payment method
      }
  }
  ...
]
```

The exact list of event types and the keys in the **details** object vary per payment method.

&#x20;**Next steps**

* [Card payments](/online-payments/mobile-sdks/card-payments.md)
* [Card payments with 3-D Secure](/online-payments/checkout/accepting-payments/3d-secure-payments.md)
* [Alternative payment methods](/online-payments/advanced-payment-methods-apms.md)
* [Theming](/online-payments/checkout/theming.md)

## APIs used to update the transaction status <a href="#apis-used-to-update-the-transaction-status" id="apis-used-to-update-the-transaction-status"></a>

Actions that can be performed on a transaction after it was initiated are listed in the [Verifone eCommerce API](/api-reference/open-api-references/ecommerce.md).


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.verifone.com/online-payments/checkout/accepting-payments.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
