# What is a Payment Page

A payment page is a secure, hosted form provided by Hyp Pay. This is where your customers enter their credit card details to pay for their purchase. When you use one of our hosted pages, the sensitive payment data goes directly from the customer's browser to Hyp's secure servers. This means it never passes through your system.

## Why you need a payment page

The main reason to use a payment page is [PCI DSS compliance](/pay/security/compliance-and-security-overview.md). These are the standard security rules that everyone in the payment industry must follow. They prohibit merchants from handling or storing raw credit card data unless they meet very strict (and expensive) security requirements.

By using a hosted payment page, you make sure your servers never see or touch the actual credit card number. This **massively reduces your compliance burden**. It also keeps your customers' data much safer since you're not the one responsible for protecting their card details.

## Payment page flow

Here's a high-level look at how the payment flow works. We've included both what the customer does on your site and the background talk between your server and Hyp Pay.

1. The customer browses your site and adds items to their cart.
2. At checkout, your server sends an API request to Hyp Pay to start the transaction. This request includes things like the amount, currency, and customer details.
3. Hyp Pay checks the request and gives your server a set of parameters, including a unique signature, that is ready to be converted into a payment page URL.
4. Your server constructs the payment page URL and your website redirects the customer to it. You can also open it in an iframe to keep the customer on your site.
5. The customer picks how they want to pay (like credit card, Apple Pay, or bit) and enters their details.
6. Once they click **Pay**, Hyp Pay handles the rest with the credit card company and any other financial entities that are involved.
7. Hyp Pay figures out if the payment worked and sends the customer back to your site using the success and error URLs you provided in your Hyp Pay account during [initial setup](/pay/getting-started/prerequisites-and-initial-setup.md).
8. This redirect includes extra information in the URL parameters, like a transaction ID and customer data.
9. Your server uses these details to make an additional API call to Hyp that checks whether the transaction has indeed occurred. This is to make sure that no one malicious has attempted to feed you fake transaction data.
10. After validation, your server updates your database to reflect the transaction, and shows the customer a final confirmation or error message.

{% @mermaid/diagram content="sequenceDiagram
participant C as Customer (in browser)
participant M as Merchant website
participant H as Hyp Pay

```
C->>M: Browses site, adds items to cart
C->>M: Clicks "Checkout"
M->>H: API request: Create payment page (APISign)
H-->>M: Response: Parameters (including a signature) for payment page URL

M-->>C: Redirect / iframe to payment page URL
C->>H: Enters card details, clicks Pay
H->>H: Process transaction & determine status

H-->>C: Redirect to merchant’s success / failure URL
C->>M: Lands on redirect page with URL parameters (transaction ID etc.)

M->>H: API call: Verify transaction
H-->>M: Response: Transaction status

M->>M: Update internal DB
M-->>C: Show confirmation or error message" %}
```

## When you don't need a payment page

Payment pages are great for securely taking new card details. However, some jobs are done using **direct API calls** without the customer even knowing. These usually happen after a customer has already made their first payment through a payment page.

### Direct API operations

You use direct API calls for the following scenarios:

* [**Refunds**](/pay/common-use-cases/refunds.md) and [**cancellations**](/pay/common-use-cases/cancellations.md): Returning funds to a customer for a previous transaction or canceling a transaction before it settles.
* [**Charging using a saved token**](/pay/common-use-cases/tokenization.md): Processing a new transaction for a returning customer using a previously saved secure card token.
* [**Recurring payments**](/pay/advanced-features/recurring-payments.md): Executing scheduled charges for subscriptions where the card was tokenized during the initial signup.
* [**Payouts**](/pay/advanced-features/payouts.md): Proactively crediting a customer's card without a linked previous transaction.

### Prerequisites for direct API calls

To use these direct calls, you need **a token**. Since you can't handle raw credit card numbers, you must use a token obtained from Hyp. This is a unique 19-digit number we generate when the customer first uses a payment page. You store this token in your own database and use it instead of the card number for any future API calls.

For more information on how tokens work, see [Tokenization](/pay/common-use-cases/tokenization.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://developers.hyp.co.il/pay/introduction/what-is-a-payment-page.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.