Question from Reddit user:
Hi Everyone!
New to programming with HighLevel and wondering if anyone can provide any clarity on getting started / adding a custom payment processor (Helcim).
I saw this: https://help.gohighlevel.com/support/solutions/articles/155000002620-how-to-build-a-custom-payments-integration-on-the-platform but I’m struggling to correlate the 3rd major step (Create a service running in any cloud provider to handle all requests from GHL while payments are happening.) with the payment flow diagram shown lower down.
Does this service correlated to the “Payment iframe”?
I’m trying to add Helcim and use it to pay from a calendar booking page.
Any tips greatly appreciated!
Answer from Nabil:
The short answer is:
No, the external service running in a cloud provider is not the same as the “Payment iframe,” but it is the essential backend brains that powers the payment process happening within that iframe.
The HighLevel documentation is describing a standard client-server interaction where the iframe is the customer-facing interface, and your cloud service is the secure, hidden engine that communicates with the Helcim API to actually process the credit card charge, and then reports the result back to HighLevel.
To use Helcim for calendar booking payments, you absolutely must successfully build and host this external service to handle the communication between the HighLevel system and the Helcim API.
The long answer is:
The confusion between the service and the iframe is common when dealing with custom payment integrations, but understanding their separate roles is key to getting Helcim working with your calendar bookings.
Think of the payment flow as having two distinct parts: the frontend and the backend.
The “Payment iframe” is the frontend, which is a public page you host (the paymentsUrl mentioned in the docs) that gets embedded into the HighLevel checkout/booking page.
This iframe is where the customer enters their card details, and importantly, this page must use a secure method like HelcimPay.js to collect the card data and send it directly to Helcim, bypassing your server for PCI compliance.
The “service running in any cloud provider” is the backend.
This is your server-side application (hosted on something like Google Cloud Platform) that handles all the secure, server-to-server API calls.
It has two main jobs in the payment flow: first, it needs to securely store the API keys HighLevel sends to it and, second, it acts as the necessary intermediary.
When the customer completes payment in the iframe, the iframe sends an event to HighLevel.
HighLevel then makes a backend API call to your cloud service’s queryUrl to verify the payment’s success using the transaction ID.
Your service then uses the Helcim API to look up the transaction details and sends a successful or failed response back to HighLevel’s API.
This two-step verification is what tells the HighLevel calendar system that the payment is complete, allowing the booking to finalize and the contact workflow to trigger.
The custom app you are building is the crucial bridge, which is why a robust solution involves tying together the HighLevel API and the Helcim API.
Using a containerized environment on Google Cloud Platform along with a server-side tag manager like Stape and a front-end handler like Google Tag Manager can significantly streamline this complex process.
This advanced setup allows you to meticulously control the data exchange between all three parties – HighLevel, your cloud service, and Helcim – ensuring the payment process is fast, reliable, and properly updates the contact record in real-time, which is exactly what you need for a smooth calendar booking and payment experience.
About The Author
