Use Checkout to complete one integration and enjoy the benefits of multiple payment methods.

Both Embedded and Hosted Checkout are secure. You must add an SSL certificate to your website.

To show a particular payment method by default, set the defaultPaymentMethod for your Checkout request. If defaultPaymentMethod=CARD, the customer first sees the card widget when Checkout renders. They can go back to see other payment methods.

Checkout and the payment methods appear differently across payment extensions because the different payment extensions (Shopify, Wix, WooCommerce, and so on) have different capabilities. Some of them enable you to configure which payment methods appear while others don't.

No, you cannot add a local domain to the allowlist. You can only add publicly accessible domains.

A Checkout session lasts 30 minutes. Customers have that time to complete a payment, whereafter the session expires.

If you receive a CORS error when integrating Checkout, ensure that you are not executing API calls that should happen from your backend on your frontend. Do not authenticate on the user interface as this exposes your Peach Payments credentials to your customers.

If a Checkout ID is not used:

• Define your own timeout period (for example, 30 minutes) after which you can consider the transaction as expired or failed if your customer does not make payment and the system does not return a status.
• If your customer later completes the payment, use the webhook notification to override the previous state and update the transaction.

Yes. Although Peach Payments is not a built-in payment provider, Lovable can build a custom integration using either Hosted Checkout or Embedded Checkout.

To get the best results when integrating Peach Payments in Lovable, point Lovable to the Peach Payments documentation. Lovable generates code by following the references that you give it. If you do not point Lovable to the Peach Payments documentation, it tries to guess the API and produces an integration that does not match the real endpoints, authentication flow, or response codes. This is the most common source of integration issues for Lovable merchants.

Before you ask Lovable to build the integration, give it links to:

• The Checkout integration that you want to use:
  • Hosted Checkout
  • Embedded Checkout
• Checkout authentication
• Checkout webhooks
• The Checkout Postman collection and sample projects
• Checkout Lovable FAQ
• Result codes

When you describe what you want, specify the Checkout version (for example, "Hosted Checkout V2") so that Lovable does not mix V1 and V2 patterns.

Yes, you must add your Lovable domain to the allowlist. Add the following to the Checkout allowlist in the Peach Payments Dashboard:

• Your published domain, for example your-app.lovable.app or your custom domain if you've connected one.
• Your preview domain, for example, preview--your-app.lovable.app. This is the domain that you see if you click Open preview in new tab in the Lovable interface.
• If you want to test payments from the preview pane inside the Lovable editor, you'll also need to allowlist <project-id>.lovableproject.com, for example, c1587b85-2b1a-48a9-8b37-7e582712836f.lovableproject.com. Retrieve the project ID from the browser's address bar of the Lovable editor.

If you haven't allowlisted the correct domains, you'll get a Merchant domain is not allowlisted error.

If you're getting an Invalid request body error, ask Lovable to provide the actual response from Peach Payments and try again. If the error is value does not match regex '^(http:\\/\\/www\\.|https:\\/\\/www\\.|http:\\/\\/|https:\\/\\/)[a-z0-9]+([\\-\\.]{1}[a-z0-9]+)*\\.([a-z]{2,63}|[0-9]{1,3})(:[0-9]{1,5})?(\\/.*)?$', then your shopperResultUrl is not in a format that Peach Payments accepts. Ask Lovable to update shopperResultUrl to a fully qualified URL in lowercase that begins with http:// or https://, for example https://your-app.lovable.app/checkout/return.

Always store your Peach Payments credentials in your backend, never in the Lovable frontend. Use a backend (for example, a Supabase Edge Function) to authenticate with Peach Payments, create the Checkout ID, and verify the payment status. The Lovable frontend must only call your backend; your backend then calls Peach Payments.

To test a Lovable integration before going live, use your sandbox credentials while you build and test in Lovable. Complete the full flow end to end in sandbox, including creating a checkout, completing a payment, and receiving webhook notifications, before you switch to your live credentials.

When Lovable produces a Peach Payments integration that does not work, capture the actual response from Peach Payments rather than the generic error that Lovable shows. Ask Lovable to surface the underlying response from your backend. At a minimum, log the result.code, result.description, and id returned by your backend's call to Peach Payments. You can then look up the code in the result codes reference, paste those values back into Lovable so it can correct the integration, or share them with Peach Payments Support. Screenshots of generic frontend errors are not enough for support to diagnose the problem.

This FAQ describes the differences between Embedded and Hosted Checkout and highlights the benefits of Embedded Checkout.

If you create an Embedded Checkout ID but don't use it, Peach Payments returns the following statuses:

• If the checkout URL is never opened:
  • The system does not trigger a webhook after 30 minutes.
  • A GET status call returns only the basic checkout information, with no result code.
• If a customer opens the checkout URL but doesn't make a payment:
  • The successfully created checkout webhook triggers.
  • After checkout times out, the system sends a Uncertain status - probably cancelled by user webhook.

Your customers might see a blank screen after choosing to pay with card if they're experiencing network issues like ISP throttling, firewall blockages, IP routing problems, or DNS issues. They could also have disabled third-party cookies or have an antivirus program that is affecting their checkout experience. They should check for issues like these before attempting to pay again.

If you create a Hosted Checkout ID but don't use it, Peach Payments returns the following statuses:

• If the checkout URL is never opened:
  • For the first 30 minutes, a GET status call returns the 700.400.580 result code.
  • After 30 minutes, the system automatically triggers a webhook with the 000.200.100 result.code.
  • After another 30 minutes (total 60 minutes), the system sends a webhook with the 100.396.104 result.code marking the checkout as expired or cancelled.
• If a customer opens the checkout URL but doesn't make a payment:
  • The successfully created checkout webhook triggers.
  • After checkout times out, the system sends a Uncertain status - probably cancelled by user webhook.

Your customers get a Could not find Checkout details. error when they refresh their browser after entering checkout.

After checkout loads, customers should not refresh their browsers during the payment process. They must either cancel the payment or close the browser and go back to your site to create a new checkout.

For Hosted Checkout V1, you can't reuse the signature generated for the payment request to get the payment status because its encryption input is different. See the Hosted Checkout V1 authentication and authorisation section for details on how to generate a signature for the payment status call.