FAQ
Is it always necessary to provide the payer's e-mail when creating a payment?
Yes, always. If you do not provide the e-mail, the payment gateway will request it itself — but the Checkout SDK cannot do this for you. Therefore, please ensure that the payer's e-mail is part of every payment right from the start.
Can the Checkout SDK be used in an iframe or WebView?
No, unfortunately. In these environments, payment methods behave unpredictably and we cannot guarantee that they will work correctly. The SDK needs to run directly on the page.
Can the Checkout SDK be used in a server-rendered JavaScript application (SSR)?
Yes, it can. Just be careful about one thing: all code that works with the SDK (useCheckout() etc.) must run in the browser, not on the server.
The SDK needs window and document — and those simply don't exist on the server.
How to test Apple Pay locally?
With Apple Pay it's a bit more complicated — Apple has strict requirements and on localhost it just isn't possible.
But don't worry, we have a solution: you can spoof the domain to checkout1.comgate.dev or checkout2.comgate.dev and test through it. You can find the guide in the documentation on the pre-registered development domain.
How to test Google Pay locally?
This one is easy! Just set environment: 'test' during configuration and Google Pay will switch to test mode — it will offer you test cards that you can safely try the payment with.
Do I have to implement 3D Secure?
No, not at all! You don't have to worry about 3D Secure — the SDK handles it completely on its own. It gradually tries the best display method (iframe → new window → redirect) and you don't need to write a single extra line of code.
What is Click to Pay and do I need to configure it?
Click to Pay is a feature that offers customers saved cards for faster payment. It is an automatic part of the card form — you don't need to set up anything, you don't need to configure anything. It just works.
Can useCheckout() be called multiple times?
Yes, but with a caveat. The Core module is a singleton — on the next call to useCheckout(), no new instance is created, only the callbacks (onPaid, onCancelled, …) are updated. Previously passed callbacks are replaced with new ones.
In SPA applications, do not forget to call destroy() on the Apple Pay, Google Pay and Card modules before leaving the page — see Cleaning up instances.
How to hide the payment method button if it is not available?
Check the result of useCheckout(). If a module returns success: false, hide the corresponding container:
useCheckout({ /* ... */ }).then((result) => {
if (result.applepay && !result.applepay.success) {
document.getElementById('cg-applepay-box').style.display = 'none';
}
});
What does the onPending callback mean?
It means that this specific attempt did not go through (e.g. the customer entered the wrong PIN), but the payment as such is still alive. You don't need to create a new one — just offer the customer to try again. Just clicking the button again is enough.
👉 More questions and answers will be added gradually.