[Bug Report: API Field Missing] GHL Custom Payment Provider — payment_initiate_props Never Fires (Bug Report)

[micheljacson-0312]

🐛 Describe the Bug

Our custom payment provider iframe never receives the payment_initiate_props event from HighLevel, so checkout can never load.

When a customer opens an invoice or payment link, HighLevel loads our registered paymentsUrl iframe (HTTP 200, confirmed in Network tab). The iframe loads correctly and repeatedly dispatches the documented custom_provider_ready event to window.parent. However, HighLevel never dispatches payment_initiate_props back — in fact it sends NO postMessage of any kind.

We verified this with an in-iframe postMessage logger: over 12+ seconds, the iframe records 30+ outbound custom_provider_ready messages and ZERO inbound messages from the parent.

The custom provider is fully configured and verified via HighLevel's own API (GET /payments/custom-provider/connect?locationId=... returns 200 with live + test config), and the sub-account UI shows the provider Connected + Default in both live and test modes. So this is not a "provider not connected" problem.

This is the same behavior as issue #281 (custom provider iframe never receives payment_initiate_props; entity-providers resolves entityId=undefined).

Environment:

• App: "Payfast Connect by 10x Digital Ventures" (marketplaceAppId: 69cf97f0050116492e8bbd4a)
• Sub-account / Location ID: XATuRqXAuNpHyAST9U1b
• paymentsUrl: https://payfast.10xdigitalventures.com/checkout
• Test payment link (still fails on a brand-new link): https://link.profdrjaved.com/payment-link/6a4c9347c981f3feae6e7d25

📍 API Endpoint

/payments/custom-provider/connect (frontend checkout host → payment_initiate_props postMessage handshake)

✅ Expected Behavior

After our iframe dispatches { type: 'custom_provider_ready', loaded: true } to window.parent, HighLevel should dispatch the payment_initiate_props event back to the iframe containing the payment context (publishableKey, amount, currency, mode, orderId/transactionId, contact, locationId).

The iframe would then render the payment form and process the payment.

💻 Screenshots or Code Samples

Our outbound handshake (fires correctly, every ~400ms):

window.parent.postMessage(

{ type: 'custom_provider_ready', loaded: true, addCardOnFileSupported: true },

'*'

);

In-iframe postMessage log (from our debug overlay):

ℹ inIframe=true · referrer=https://link.profdrjaved.com/ · ancestorOrigins=[https://link.profdrjaved.com/]

⬆ OUT custom_provider_ready → 1 ancestor(s)

⬆ OUT custom_provider_ready → 1 ancestor(s)

... (repeats 30+ times over 12 seconds)

[no messages received from parent] ← ZERO inbound messages

Provider config proof — GET /payments/custom-provider/connect?locationId=XATuRqXAuNpHyAST9U1b → 200:

{

"locationId": "XATuRqXAuNpHyAST9U1b",

"marketplaceAppId": "69cf97f0050116492e8bbd4a",

"paymentsUrl": "https://payfast.10xdigitalventures.com/checkout",

"providerConfig": {

"live": { "liveMode": true, "publishableKey": "pk_c18aba88f8001f9d976df4c026488964" },

"test": { "liveMode": false, "publishableKey": "pk_c18aba88f8001f9d976df4c026488964" }

}

}

Sub-account UI confirms: live mode enabled ✅, test mode enabled ✅, provider set as Default ✅.
Network: initiate → 201, entity-providers?altId=XATuRqXAuNpHyAST9U1b&altType=location → 200, display → 201, /checkout iframe → 200.

Test payment link (fails on a brand-new link too): https://link.profdrjaved.com/payment-link/6a4c9347c981f3feae6e7d25

Same behavior as issue #281 (entity-providers resolves entityId=undefined; payment_initiate_props never dispatched).

---

Product Area *(dropdown) → payments select karo (agar list mein payments ho). Agar payments na ho to other / sabse qareeb wala.

Product Area

payments

📋 Use Case

We are shipping a custom payment provider (PayFast for Pakistan) so HighLevel sub-accounts can collect payments on invoices, payment links, funnels, and subscriptions through their own gateway.

The integration is completely blocked at the final step: HighLevel loads our checkout iframe but never dispatches payment_initiate_props, so no customer can pay. Everything on our side is verified working (provider registered, connect config saved, live + test modes enabled, provider set as Default, ready handshake firing, TLS + no-store cache headers). We need HighLevel to dispatch the payment context event so checkout can function.

🚨 Why Should This Be Prioritized?

This is a complete, revenue-blocking outage for the integration:

• It fully blocks our ability to collect ANY payment through the custom provider — 0% success rate.
• Every customer of this sub-account (and every future sub-account installing our app) is affected — they cannot pay a single invoice or payment link.
• We are losing 100% of revenue through this gateway; clients cannot go live.
• This prevents us from launching our marketplace payment app entirely.
• Our side is fully verified correct (provider Connected + Default in live & test, ready handshake confirmed via postMessage logging, brand-new payment link still fails), so the blocker is on the HighLevel platform side, matching issue [BUG] payment_initiate_props never dispatched after custom_provider_ready in invoice flow — contradicts documented behavior #281.

🧠 Additional Context

• Same symptom as issue [BUG] payment_initiate_props never dispatched after custom_provider_ready in invoice flow — contradicts documented behavior #281 (custom provider iframe never receives payment_initiate_props; entity-providers resolves entityId=undefined).
• Reproduced on BOTH an existing invoice and a brand-new payment link, so it is not a stale/cached entity.
• Only ONE ancestor frame exists (ancestorOrigins=[https://link.profdrjaved.com]); our custom_provider_ready reaches it, but zero inbound messages are ever received.
• Sub-account / Location ID: XATuRqXAuNpHyAST9U1b
• Marketplace App ID: 69cf97f0050116492e8bbd4a
• Test payment link (for your reproduction): https://link.profdrjaved.com/payment-link/6a4c9347c981f3feae6e7d25
• Happy to provide a screen recording, HAR file, or grant test access on request.

[github-actions]

✅ Issue processed successfully!

Your issue has been reviewed and assigned to the appropriate team.

[micheljacson-0312]

till when it will be resolved?
@i-am-rad
@manit-highlevel

[i-am-rad]

Check how your sending the payload back when letting them know your ready replying to the post message. I had a similar issue, but the expectation is sending as JSON body.

[micheljacson-0312]

Check how your sending the payload back when letting them know your ready replying to the post message. I had a similar issue, but the expectation is sending as JSON body.

Thanks @i-am-rad — good call, but we've already ruled that out on our side.

1. Payload format is correct. We post a plain object (not a stringified JSON body), so event.data.type resolves fine:
   js window.parent.postMessage( { type: 'custom_provider_ready', loaded: true, addCardOnFileSupported: true }, '*' );
2. Single ancestor. We send this to window.parent only, and the message goes out correctly — the ready signal is confirmed leaving our iframe.
3. Provider is already connected and set as Default in the sub-account, in the same mode (live vs test) as the invoice. So the usual "not default / wrong mode" cause doesn't apply here either.
   Even with all three correct, GHL loads the /checkout iframe but payment_initiate_props never fires back — our listener receives nothing after custom_provider_ready. That's why we filed this as a bug: the handshake is initiated correctly from our end but GHL isn't responding with the payment props.
   @i-am-rad @manit-highlevel — could you confirm whether anything else on the GHL side is required to trigger payment_initiate_props, or whether this is a known regression? Happy to share our checkout page source / a screen recording of the postMessage log if that helps.

[micheljacson-0312]

@i-am-rad @ajain-ghl @manit-highlevel check and resolve issue asap or give us a feedback or review on this

[i-am-rad]

Im not a ghl employee. You must stringify it. A little bit of code to help you:

`// Send to parent
window.parent.postMessage(JSON.stringify(payload), '*');

// Also send to top if it's a different window
if (window.top && window.top !== window.parent) {
window.top.postMessage(JSON.stringify(payload), '*');
}`

Keep retrying custom_provider_ready on an interval

GHL sometimes loads the iframe before its own postMessage listener is attached. This codebase sends custom_provider_ready every 500ms for up to 30 attempts (15 seconds), stopping as soon as payment_initiate_props is received:

const interval = setInterval(() => { if (receivedProps) { clearInterval(interval); return; } window.parent.postMessage(JSON.stringify({ type: 'custom_provider_ready', loaded: true }), '*'); }, 500);

[i-am-rad]

https://help.gohighlevel.com/support/solutions/articles/155000002620-how-to-build-a-custom-payments-integration-on-the-platform

[micheljacson-0312]

Im not a ghl employee. You must stringify it. A little bit of code to help you:

`// Send to parent window.parent.postMessage(JSON.stringify(payload), '*');

// Also send to top if it's a different window if (window.top && window.top !== window.parent) { window.top.postMessage(JSON.stringify(payload), '*'); }`

Keep retrying custom_provider_ready on an interval

GHL sometimes loads the iframe before its own postMessage listener is attached. This codebase sends custom_provider_ready every 500ms for up to 30 attempts (15 seconds), stopping as soon as payment_initiate_props is received:

const interval = setInterval(() => { if (receivedProps) { clearInterval(interval); return; } window.parent.postMessage(JSON.stringify({ type: 'custom_provider_ready', loaded: true }), '*'); }, 500);

oky thank you resolved