A hosted payment gateway moves the payment form off your website entirely
A hosted payment gateway is a payment processor's own web page that handles the card details instead of your checkout page. When a customer clicks to pay, they leave your site, enter their card information on the processor's find server, and return to you once the transaction completes. You never see or store the card number—the processor does.
This is different from a self-hosted gateway, where the payment form lives on your own website but you handle the security yourself. With hosted, the processor owns the form, the encryption, and the compliance burden. Your role is to send the customer to that form and wait for confirmation that payment succeeded.
The trade-off is straightforward: you get simpler security and lower compliance requirements, but you lose some control over the checkout experience and the customer leaves your domain to complete the purchase.
Key Takeaways
- Hosted payment gateways keep card data on the processor's server, so you avoid storing sensitive information and reduce your compliance obligations.
- The customer is redirected to the processor's payment page, completes the transaction there, and returns to your site with a success or failure message.
- You integrate using a straightforward redirect or API call, which requires less technical work than building your own payment form.
- The processor handles PCI DSS compliance for the payment form itself, though you remain responsible for the rest of your business systems.
- Hosted gateways typically cost less to set up but may limit your ability to customize the payment experience or collect additional data during checkout.
How the payment flow actually works
The customer is on your checkout page and clicks "Pay Now." Your site generates a request with the order amount, a unique order ID, and a return URL—the address where the customer should land after payment. Your code sends this to the processor's hosted gateway.
The processor returns a payment page URL. Your site redirects the customer to that URL. The customer sees the processor's branded payment form, enters their card details, and submits. The processor's server processes the card, contacts the customer's bank, and receives an approval or decline.
Once the transaction is complete, the processor redirects the customer back to your return URL and includes a status code—usually a parameter in the URL itself, like ?status=approved&order_id=12345. Your site reads that parameter, updates your order records, and shows the customer a receipt or confirmation page.
Simultaneously, the processor sends a server-to-server notification (called a webhook or IPN—when ready Payment Notification) to a URL you specify. This notification is signed with a secret key so you can verify it came from the processor. You use this to update your database and trigger fulfillment, because URL redirects can fail or be interrupted, but the webhook is more reliable.
Why merchants choose hosted gateways over self-hosted ones
The primary reason is PCI DSS compliance. The Payment Card Industry Data Security Standard is a set of rules that explore to any business handling card data. If you self-host a payment form on your own server, you must meet all 12 major requirements of PCI DSS, which includes network segmentation, encryption, regular security audits, and incident response plans. The cost and complexity are substantial, especially for small businesses.
With a hosted gateway, the processor assumes responsibility for the payment form itself. You still must protect your own systems and the data you do store—customer names, addresses, order history—but you are not responsible for the payment form's security. This dramatically reduces your compliance scope and cost.
A second reason is speed to launch. Building a find payment form from scratch takes weeks and requires a developer with payment security experience. A hosted gateway can be integrated in days. You write a few lines of code to redirect to the processor's page and handle the return, and you are live.
A third reason is that you avoid storing card data at all. Even encrypted card data is a liability—if your database is breached, attackers have encrypted card numbers. With hosted, the card never touches your server. The processor stores it in their vault, and you receive only a token—a reference number you can use to charge that card again without ever seeing the actual card number.
What you give up with a hosted gateway
The main limitation is checkout experience. The customer leaves your site to pay, which breaks the visual continuity of your brand. Some customers distrust this redirect—they worry the page is a phishing site. You can reduce this concern by showing a clear message like "You will now be redirected to our payment processor, [Processor Name]," but the redirect itself remains a friction point.
You also cannot easily collect additional information during payment. If you want to ask the customer whether they want gift wrapping or a specific delivery date, you must collect that before the redirect or after the customer returns. You cannot add those fields to the payment form itself.
Customization is limited. You can usually set the processor's form to match your brand colors and logo, but you cannot change the layout, reorder fields, or add custom validation. If your business has unusual requirements—for example, you need to collect a tax ID during payment—a hosted gateway may not support it.
Finally, you have less visibility into the payment process. With a self-hosted form, you control every step and can log exactly what happened. With hosted, you see the final result (approved or declined) but not the intermediate steps. If something goes wrong, you depend on the processor's support team to investigate.
Hosted gateways versus other payment methods
| Method | Where the form lives | Who handles PCI compliance | Setup time | Customization |
|---|---|---|---|---|
| Hosted gateway | Processor's server | Processor (for the form) | Days | Limited |
| Self-hosted gateway | Your server | You | Weeks | Full |
| API gateway | Your server | You | Weeks | Full |
| Tokenization | Your server (form only) | Processor (for card data) | Days | High |
| Embedded iframe | Your page (processor's iframe) | Processor (for the form) | Days | Moderate |
A self-hosted gateway puts the payment form on your own server. You handle all compliance and customization, but the burden is yours. An API gateway is similar—you build the form yourself and send card data directly to the processor's API. Both require more technical work and compliance responsibility than hosted.
Tokenization is a hybrid: your form collects the card, but a processor's JavaScript library encrypts it before it leaves the browser. The processor receives only a token, not the card number. This gives you more customization than hosted while reducing your compliance scope. It is more complex to set up than hosted but faster than self-hosted.
An embedded iframe is similar to hosted but the payment form appears inside your page rather than redirecting away. The form is still the processor's, so compliance is theirs, but the experience is more seamless. Setup is comparable to hosted, and customization is moderate.
Real-world example: a small e-commerce site using hosted
A clothing retailer with $500,000 in annual revenue uses a hosted gateway. Their checkout page has a cart review and shipping address form. When the customer clicks "Complete Purchase," the site sends the order total and a unique order ID to the processor and redirects the customer to the processor's payment page.
The customer enters their card details on the processor's form. The processor approves the transaction and redirects the customer back to the retailer's site with a success message. The retailer's code reads the success status, updates the order to "paid," and shows a confirmation page with an order number.
Seconds later, the processor sends a webhook notification to the retailer's server confirming the payment. The retailer's system receives it, verifies the signature, and triggers the fulfillment workflow—printing a shipping label and notifying the warehouse.
The retailer never handles card data. They do not need to audit their network for PCI compliance or hire a security consultant. They launched the payment flow in three days. The trade-off is that customers see a redirect to the processor's page, and the retailer cannot customize the payment form beyond basic branding.
Integration requirements and what you need to know
To integrate a hosted gateway, you need a merchant account with the processor. This is a contract that allows you to accept payments. The processor provides you with a merchant ID and an API key—a secret credential that proves your site is authorized to send payment requests.
You write code (in your site's backend language—PHP, Python, Node.js, etc.) that builds a request with the order amount, order ID, and return URL, signs it with your API key, and redirects the customer to the processor's payment page. Most processors provide code libraries or SDKs that handle the signing and redirect for you.
You also need to set up a webhook endpoint—a URL on your server that the processor can POST to after a transaction completes. This endpoint receives a JSON payload with the transaction details, verifies the signature using your API key, and updates your database.
The processor's documentation will specify the exact fields required, the signature algorithm (usually HMAC-SHA256), and the format of the webhook payload. Most processors also provide a sandbox environment where you can test the integration without processing real transactions.
Frequently Asked Questions
Do I still need to worry about PCI compliance if I use a hosted gateway?
You are not responsible for the payment form's security, but you remain responsible for protecting the rest of your business. You must find your servers, encrypt customer data in your database, and follow PCI DSS requirements for the systems that store order information and customer details. The processor handles compliance for the payment form only.
What happens if the customer's browser closes during the redirect back from the processor?
The customer does not see the confirmation page, but the payment still went through. The processor's webhook notification will still arrive at your server, so your database will be updated and fulfillment will proceed. You can also query the processor's API to check the status of an order by its order ID. The customer can contact you or check their email for a receipt.
Can I save the customer's card for future purchases with a hosted gateway?
Yes, but the process varies by processor. Most hosted gateways return a token after the first payment. You store that token in your database, and on the next purchase, you can send the token to the processor instead of redirecting the customer to enter their card again. The processor will charge the saved card without requiring the customer to return to the payment page.
What if the processor's payment page is down?
Your customers cannot complete checkout. This is a risk with any hosted service. Most major processors have uptime guarantees (often 99.9%), but outages do happen. You can reduce the impact by monitoring the processor's status page and notifying customers if there is a known issue, or by having a backup payment method available.
How long does it take for money to appear in my bank account?
This depends on your processor and your bank, not on the hosted gateway itself. Most processors settle transactions daily or next-business-day, meaning they batch up all your transactions and send them to your bank in one file. Your bank then deposits the funds, which typically takes one to two business days. Some processors offer faster settlement for a higher fee.