Skip to content
Docs/
/Checkout

Checkout

This guide uses the Glomo Unified SDK — see it for the full set of journeys and options. To open checkout inside a native mobile app, see Web Checkout in a Mobile App (WebView). If you integrated earlier with the older checkout-sdk, it continues to work — switch the import to the Unified SDK when convenient.

Migrating from the legacy checkout-sdk? Two behaviour differences to note:

  • When callbackUrl is set, the Unified SDK only redirects — it no longer also fires your .on('payment.success') / .on('payment.failure') / .on('payment.bank_transfer_submitted') handlers (the legacy SDK did both). checkout.closed is unaffected.
  • on() now returns an unsubscribe function (call it to remove the listener); the legacy SDK returned nothing.

Glomo Checkout offers a prebuilt payment form that enables businesses to securely accept payments online. With its built-in features, you can minimize development time and streamline the payment process. Embed Checkout directly into your website, or direct customers to a Glomo-hosted payment page to start accepting payments.

Checkout requires minimal coding because of its prebuilt functionalities and customization options. You can integrate Checkout by creating a Checkout Session and collecting the customer’s payment details.

Checkout Interface

End-to-End Flow in Accepting Payments

Below are the steps that are to accept payments :-

1

Once the customer initiates payment on the merchant’s website - Create an order by making server to server call

→
2

Use order ID to involve the checkout form

→
3

User selects a payment option on checkout and enters relevant information - Collect Payment details

→
4

Glomo authenticates the payment information

→
5

Verify Payment status returned and redirect the user to the payment confirmation page

Visual Representation of Payment Flow

A visual representation for the sequence of steps is given below :-

Payment Flow Diagram

Steps to integrate Checkout

Note: We recommend using ES module imports for the Glomo Checkout SDK. While UMD format is still supported for legacy compatibility, it is not actively maintained. For optimal performance and future support, please use ES modules. If you absolutely require UMD format, please contact our support team for assistance.

1. Create an Order in Server
  • You will have to create an order from your server using the secret keys.
  • You can get the secret key on your glomopay dashboard.
  • You can create order by integrating our Order APIs.It should be a server side api call. Refer Authentication for details around how to authenticate Order's API.
  • The order_id received in the response should be passed to the checkout. This ties the order with the payment and secures the request from being tampered.
2. Add payment button on client
  • Add a buy button on your website.
  • You can integrate the checkout by adding the below code snippet to your website.
  • The code snippet will create a checkout instance and open the checkout form when the user clicks on the buy button.
  • The orderId of the order created via your server in step 1 should be passed to the checkout instance.
  • The publicKey refers to the public key of your Glomo account present on your dashboard.
  • Handle the payment success and failure events, in the handlers function you will get payment object or error object based on the payment status. Collect these and send them to your server and retry accordingly in case payment failed.
  • For bank transfer payments, a payment.bank_transfer_submitted event is emitted when the user submits their payment details on the checkout. This event only indicates that the user has submitted payment details; it does not confirm that the payment has been completed or verified — please wait for webhooks to determine the final payment status.
  • Additionally, you can also provide a callbackUrl to redirect the user after payment completion. If you provide a callbackUrl, the user will be redirected to that URL after payment completion with the payment status and other details in the query parameters.
  • If callbackUrl is provided,failure and success events will not be triggered in the checkout instance.
  • Checkout opens as an overlay on your page. To detect a customer closing it without paying, listen for checkout.closed (see Handling Abandoned Checkouts). It fires whether or not you set callbackUrl.
  <!-- your-page.html -->
  <button id="buy-button" class="buy-button">Buy Now</button>

  <!-- Load the integration from a file so a strict CSP does not need 'unsafe-inline'. -->
  <script type="module" src="/glomo-checkout.js"></script>
  // glomo-checkout.js
  import { GlomoCheckoutApi } from 'https://unified-sdk.glomopay.com/index.js';

  const checkout = new GlomoCheckoutApi({
    orderId: 'order_679a16457aP6K', // Pass the order_id received from the server in step 1
    publicKey: 'live_687b0151Bid24PAI', // Pass the public key received from the dashboard
    callbackUrl: 'https://yourwebsite.com/payment-result', // Optional: URL to redirect after payment completion
  });

  document.getElementById('buy-button').addEventListener('click', () => {
    checkout.open();
  });

  checkout.on('payment.success', function (response) {
    // Handle payment success
  });

checkout.on('payment.failure', function (response) {
    // Handle payment failure
  });

  // Bank transfer only: emitted when the user submits their payment details.
  // Does NOT mean the payment is successful — await a webhook for confirmation.
  checkout.on('payment.bank_transfer_submitted', function (response) {
    // response.orderId - the order ID
  });

  // Detect an abandoned checkout. The checkout opens as an overlay on your page and
  // emits checkout.closed when the user closes it, including after the success or
  // failure screen. The payment events fire before it, so track whether one arrived.
  // With callbackUrl set, the success and failure handlers don't run, but the page is
  // redirected on those outcomes instead, so checkout.closed only fires if the user
  // left before finishing.
  let paymentCompleted = false;

  checkout.on('payment.success', function (response) {
    paymentCompleted = true;
    // Handle payment success
  });

  checkout.on('payment.failure', function (response) {
    paymentCompleted = true;
    // Handle payment failure
  });

  checkout.on('payment.bank_transfer_submitted', function (response) {
    paymentCompleted = true; // Details submitted, not abandoned. Await a webhook for the result.
  });

  checkout.on('checkout.closed', function () {
    if (!paymentCompleted) {
      // User closed the checkout without completing payment.
      // Use this to restore your UI, log abandonment, or prompt the user to retry.
      console.log('Checkout closed without payment');
    }
    paymentCompleted = false; // Reset for the next checkout attempt
  });

About the Callback URL

When you provide a callbackUrl, the user will be automatically redirected to that URL after payment completion with the following parameters:

For successful payments:

https://yourwebsite.com/payment-result?orderId=order_679a16457aP6K&paymentId=payt_679a16457aP6K&status=success&signature=701eab675aca32c14cd1e5e041842d11ee9d04e91a3aaa73c629664a336b2952

For failed payments:

https://yourwebsite.com/payment-result?orderId=order_679a16457aP6K&paymentId=payt_679a16457aP6K&status=failed&errorCode=INVALID_CARD&errorMessage=Payment+failed+due+to+the+card+being+invalid%3B+please+use+a+different+card.

A failed redirect carries no signature, so don't trust its status on its own. Look the payment up on your server.

This allows server-side handling of payment results in addition to the client-side event handlers.

3. Verify checkout response and signature in server
  • The payment.success handler receives an object with orderId, paymentId, status and signature. The keys are camelCase.
  • The signature lets you check that the payment object came from Glomo. Send paymentId, status and signature to your server and verify the signature there. Never verify in the browser.
  • To verify, sign orderId|paymentId|status, using paymentId and status from the event and the order ID you created in step 1, not the orderId from the browser.
  • The signature is the hex HMAC-SHA256 of that string. Compute it with each of your active secret keys, and accept the response if any one of them matches the signature you received. Your active secret keys are every secret key on your account that has not expired. Use a constant-time comparison.
  • The signature may be made with any one of your active secret keys, and it can differ between payments. Don't assume it is your newest key. If you hold more than one active key, checking only one of them can reject a genuine payment.
  • When you revoke a key, or it expires, remove it from your list. A stale key left in the list opens no security hole, but keep the list matching the keys in your dashboard.
  • The payment.failure event carries no signature. Don't treat it as final. Confirm the payment status on your server (see step 4).

Cards

For card payments, payment.success and payment.failure events are triggered synchronously once the payment is processed.

Success Response

{
    "status": "success",
    "orderId": "order_679a16457aP6K",
    "paymentId": "payt_679a16457aP6K",
    "signature": "701eab675aca32c14cd1e5e041842d11ee9d04e91a3aaa73c629664a336b2952"
}

Failure Response

error.code is the payment's error code, and error.message is the message shown to the customer. When Glomo has no specific reason, error.code is "Failed" and error.message is a generic message. There is no signature.

{
    "orderId": "order_679a16457aP6K",
    "paymentId": "payt_679a16457aP6K",
    "status": "failed",
    "error": {
        "code": "INVALID_CARD",
        "message": "Payment failed due to the card being invalid; please use a different card."
    }
}

Bank Transfer

Bank transfer payments follow an asynchronous flow. The customer sends the transfer from their own bank, and Glomo matches it to the order later, often after the checkout is closed. Checkout events for bank transfers are not signed, so you cannot verify them with the signature recipe below. Confirm the payment on your server with a verified webhook, or call Retrieve an order and check for status: paid. For the full flow, see Set up bank transfers.

Bank Transfer Submitted (Intermediate)

Emitted when the customer submits the details of the account they paid from. It means the customer says they sent the transfer, not that the money arrived. Use it to show a "pending" state. It carries no signature.

{
    "status": "bank_transfer_submitted",
    "orderId": "order_679a16457aP6K",
    "senderAccountNumber": "7890",
    "senderName": "John Doe",
    "payerRelationship": ""
}

Success Response

Emitted only if the order becomes paid while the customer is still on the confirmation screen. For a bank transfer, paymentId and signature are empty, so this event cannot be verified. Do not mark the order paid from it.

{
    "status": "success",
    "orderId": "order_679a16457aP6K",
    "paymentId": "",
    "signature": ""
}

There is no bank-transfer failure event. A transfer that doesn't arrive, or can't be matched, shows up in webhooks, not in checkout. See Resolving Action Required Payments.

Sample Code to verify signature

Each sample loads your active secret keys from a comma-separated GLOMO_SECRET_KEYS setting in your config, and returns true if the signature matches any one of them. It trims each key, drops empty entries, and stops with an error if no key is left. An empty key must never count as a match: anyone can compute the signature for an empty key, so it would let a forged response through.

PHP
<?php
function load_secret_keys($value) {
    $keys = array_values(array_filter(array_map('trim', explode(',', (string) $value))));
    if (count($keys) === 0) {
        throw new RuntimeException('GLOMO_SECRET_KEYS is not set');
    }
    return $keys;
}

function verify_signature($order_id, $payment_id, $status, $signature, array $secret_keys) {
    $data = $order_id . "|" . $payment_id . "|" . $status;
    foreach ($secret_keys as $secret) {
        if ((string) $secret === '') {
            continue; // an empty key never matches
        }
        if (hash_equals(hash_hmac('sha256', $data, $secret), (string) $signature)) {
            return true;
        }
    }
    return false;
}

// Example Usage
$order_id = "order_679a16457aP6K"; // the order ID you created in step 1
$payment_id = "payt_679a16457aP6K";
$status = "success";
$signature = "e91071c1f6226faac21db65e18f45f3c93e8468ff2d67528f4be3e4412ab0cb7"; // the signature you received
$secret_keys = load_secret_keys(getenv('GLOMO_SECRET_KEYS')); // every active secret key, e.g. "your_secret_key_1,your_secret_key_2"

var_dump(verify_signature($order_id, $payment_id, $status, $signature, $secret_keys));
?>
Ruby
require 'openssl'

def load_secret_keys(value)
  keys = value.to_s.split(',').map(&:strip).reject(&:empty?)
  raise 'GLOMO_SECRET_KEYS is not set' if keys.empty?
  keys
end

def verify_signature(order_id, payment_id, status, signature, secret_keys)
  data = "#{order_id}|#{payment_id}|#{status}"
  secret_keys.any? do |secret|
    next false if secret.to_s.empty? # an empty key never matches
    OpenSSL.secure_compare(OpenSSL::HMAC.hexdigest("SHA256", secret, data), signature.to_s)
  end
end

# Example Usage
order_id = "order_679a16457aP6K" # the order ID you created in step 1
payment_id = "payt_679a16457aP6K"
status = "success"
signature = "e91071c1f6226faac21db65e18f45f3c93e8468ff2d67528f4be3e4412ab0cb7" # the signature you received
secret_keys = load_secret_keys(ENV['GLOMO_SECRET_KEYS']) # every active secret key, e.g. "your_secret_key_1,your_secret_key_2"

puts verify_signature(order_id, payment_id, status, signature, secret_keys)
Go
package main

import (
    "crypto/hmac"
    "crypto/sha256"
    "encoding/hex"
    "errors"
    "fmt"
    "os"
    "strings"
)

func loadSecretKeys(value string) ([]string, error) {
    var keys []string
    for _, key := range strings.Split(value, ",") {
        key = strings.TrimSpace(key)
        if key != "" {
            keys = append(keys, key)
        }
    }
    if len(keys) == 0 {
        return nil, errors.New("GLOMO_SECRET_KEYS is not set")
    }
    return keys, nil
}

func verifySignature(orderID, paymentID, status, signature string, secretKeys []string) bool {
    data := orderID + "|" + paymentID + "|" + status
    for _, secret := range secretKeys {
        if secret == "" {
            continue // an empty key never matches
        }
        h := hmac.New(sha256.New, []byte(secret))
        h.Write([]byte(data))
        expected := hex.EncodeToString(h.Sum(nil))
        if hmac.Equal([]byte(expected), []byte(signature)) {
            return true
        }
    }
    return false
}

func main() {
    orderID := "order_679a16457aP6K" // the order ID you created in step 1
    paymentID := "payt_679a16457aP6K"
    status := "success"
    signature := "e91071c1f6226faac21db65e18f45f3c93e8468ff2d67528f4be3e4412ab0cb7" // the signature you received
    secretKeys, err := loadSecretKeys(os.Getenv("GLOMO_SECRET_KEYS")) // every active secret key, e.g. "your_secret_key_1,your_secret_key_2"
    if err != nil {
        panic(err)
    }

    fmt.Println(verifySignature(orderID, paymentID, status, signature, secretKeys))
}
Javascript(Node.js)
const crypto = require('crypto');

function loadSecretKeys(value) {
    const keys = (value || '').split(',').map((k) => k.trim()).filter(Boolean);
    if (keys.length === 0) throw new Error('GLOMO_SECRET_KEYS is not set');
    return keys;
}

function verifySignature(orderId, paymentId, status, signature, secretKeys) {
    const data = `${orderId}|${paymentId}|${status}`;
    const received = Buffer.from(signature || '');
    return secretKeys.some((secret) => {
        if (!secret) return false; // an empty key never matches
        const expected = Buffer.from(crypto.createHmac('sha256', secret).update(data).digest('hex'));
        return expected.length === received.length && crypto.timingSafeEqual(expected, received);
    });
}

// Example Usage
const orderId = "order_679a16457aP6K"; // the order ID you created in step 1
const paymentId = "payt_679a16457aP6K";
const status = "success";
const signature = "e91071c1f6226faac21db65e18f45f3c93e8468ff2d67528f4be3e4412ab0cb7"; // the signature you received
const secretKeys = loadSecretKeys(process.env.GLOMO_SECRET_KEYS); // every active secret key, e.g. "your_secret_key_1,your_secret_key_2"

console.log(verifySignature(orderId, paymentId, status, signature, secretKeys));
Python
import hmac
import hashlib
import os

def load_secret_keys(value):
    keys = [key.strip() for key in (value or "").split(",") if key.strip()]
    if not keys:
        raise RuntimeError("GLOMO_SECRET_KEYS is not set")
    return keys

def verify_signature(order_id, payment_id, status, signature, secret_keys):
    data = f"{order_id}|{payment_id}|{status}".encode()
    received = (signature or "").encode()
    return any(
        hmac.compare_digest(hmac.new(secret.encode(), data, hashlib.sha256).hexdigest().encode(), received)
        for secret in secret_keys
        if secret  # an empty key never matches
    )

# Example Usage
order_id = "order_679a16457aP6K"  # the order ID you created in step 1
payment_id = "payt_679a16457aP6K"
status = "success"
signature = "e91071c1f6226faac21db65e18f45f3c93e8468ff2d67528f4be3e4412ab0cb7"  # the signature you received
secret_keys = load_secret_keys(os.environ.get("GLOMO_SECRET_KEYS"))  # every active secret key, e.g. "your_secret_key_1,your_secret_key_2"

print(verify_signature(order_id, payment_id, status, signature, secret_keys))
4. Verify Payment status

Payment's status can be tracked via following ways

  • You can track the payments linked to your order_id via dashboard
  • You can also track the payment status via polling Payment APIs
  • You can also track the payment status via Webhooks which will notify you about the payment status.

Troubleshooting Common Issues

Checkout Popup Blocked in Production Environment

Symptom: The checkout works perfectly in your local development environment, but when deployed to UAT or production, the payment page fails to open in a new tab/popup after clicking the "Pay Now" button.

Cause: This issue is typically caused by the Cross-Origin-Opener-Policy (COOP) security header on your website. If your website sends Cross-Origin-Opener-Policy: same-origin, it will block popups to external domains, including the Glomo payment gateway.

How to Detect This Issue

  1. Open your browser's Developer Tools (F12 or Right-click → Inspect)
  2. Go to the Network tab
  3. Reload your page and click on the main document (usually the first entry)
  4. Look at the Response Headers section
  5. Check if you see: Cross-Origin-Opener-Policy: same-origin

If you see this header with the same-origin value, this is what's blocking the checkout popup.

Solution

Update your server's COOP header configuration from:

Cross-Origin-Opener-Policy: same-origin

to:

Cross-Origin-Opener-Policy: same-origin-allow-popups

How to implement this depends on your setup:

Apache (.htaccess)
Header set Cross-Origin-Opener-Policy "same-origin-allow-popups"
Nginx
add_header Cross-Origin-Opener-Policy "same-origin-allow-popups";
Node.js/Express
app.use((req, res, next) => {
  res.setHeader('Cross-Origin-Opener-Policy', 'same-origin-allow-popups');
  next();
});
Next.js (next.config.js)
module.exports = {
  async headers() {
    return [
      {
        source: '/(.*)',
        headers: [
          {
            key: 'Cross-Origin-Opener-Policy',
            value: 'same-origin-allow-popups',
          },
        ],
      },
    ];
  },
};

Verifying the Fix

After deploying the header change:

  1. Clear your browser cache (or use incognito/private mode)
  2. Reload your website
  3. Open Developer Tools → Network tab
  4. Verify the header now shows: Cross-Origin-Opener-Policy: same-origin-allow-popups
  5. Test the checkout flow again

Note: The same-origin-allow-popups value maintains security for your website while allowing the checkout to open properly in a new window.

CORS Error on Checkout Load (Preferences API Failure)

Symptom: After successfully opening the checkout, you see a CORS (Cross-Origin Resource Sharing) error in the browser console when the checkout tries to load. The error typically mentions the preferences API call failing with a message like:

Access to fetch at 'https://...' from origin '...' has been blocked by CORS policy

Cause: This issue is often caused by browser extensions that intercept or modify network requests. Common culprits include ad blockers, privacy extensions, VPN extensions, and other security-focused browser add-ons.

How to Detect This Issue

  1. Open your browser's Developer Tools (F12)
  2. Go to the Console tab
  3. Load the checkout and look for CORS-related errors
  4. The error will typically mention "blocked by CORS policy" or "No 'Access-Control-Allow-Origin' header"

Solution

Step 1: Test in Incognito/Private Mode

The quickest way to verify if a browser extension is causing the issue:

  1. Open an incognito/private browsing window (most extensions are disabled by default)
  2. Test the checkout integration again
  3. If the checkout works in incognito mode, a browser extension is the culprit

Step 2: Identify and Disable Interfering Extensions

If the checkout works in incognito mode:

  1. Go to your browser's extensions page:
    • Chrome/Edge: chrome://extensions or edge://extensions
    • Firefox: about:addons
    • Safari: Preferences → Extensions
  2. Disable extensions one by one, especially:
    • Ad blockers (AdBlock, uBlock Origin, etc.)
    • Privacy extensions (Privacy Badger, Ghostery, etc.)
    • VPN or proxy extensions
    • Security extensions
    • Request interceptors or modifiers
  3. Test the checkout after disabling each extension
  4. Once you identify the problematic extension, keep it disabled for your domain or whitelist your website

For Developers: Communicating with Users

If your customers report this issue, provide them with these troubleshooting steps:

  1. Try testing in incognito/private browsing mode
  2. If it works there, ask them to temporarily disable browser extensions
  3. Common extensions that cause issues: ad blockers, VPN extensions, privacy tools

Note: This is not an issue with Glomo's checkout or your integration - it's a side effect of browser extensions modifying network behavior. The checkout will work correctly once interfering extensions are identified and configured properly.

Content Blocked by Content Security Policy (CSP)

Symptom: When attempting to load the Glomo Checkout, you see a message stating "This content is blocked. Contact the site owner to fix the issue." The checkout iframe or SDK scripts fail to load.

Cause: Your website has Content Security Policy (CSP) headers configured that are blocking the Glomo Checkout SDK from loading its scripts, iframe, and making API calls. CSP is a security feature that restricts which external resources can be loaded on your page.

How to Detect This Issue

  1. Open your browser's Developer Tools (F12 or Right-click → Inspect)
  2. Go to the Console tab
  3. Look for errors mentioning "Content Security Policy" or "CSP", such as:
    Refused to load the script 'https://unified-sdk.glomopay.com/...' because it violates the following Content Security Policy directive...
    Refused to frame 'https://unified-sdk.glomopay.com/' because it violates the following Content Security Policy directive...
  4. You can also check the Network tab → click on your page's main document → Response Headers → look for Content-Security-Policy header

Solution

Update your CSP configuration to allow the Glomo Checkout SDK domains. You need to add the following domains to your CSP directives:

DomainPurpose
https://unified-sdk.glomopay.comSDK scripts, iframe, and source maps
https://*.glomopay.comCheckout modal and API calls

Add these domains to the following CSP directives:

  • script-src: Allows loading the SDK JavaScript
  • frame-src: Allows embedding the checkout iframe
  • connect-src: Allows API calls to Glomo services

The examples below do not include 'unsafe-inline' in script-src. The SDK is loaded as an external ES module, so the origin above is sufficient on its own — and keeping 'unsafe-inline' in script-src is commonly raised as a finding in security reviews, because it permits any inline script on your page to execute.

This means your own integration code must not sit in an inline <script> block either. type="module" does not exempt it — under CSP, a script is "inline" whenever the <script> tag has no src attribute. Either of these works:

  • Load it from a file (recommended, and what the HTML example above does):

    <script type="module" src="/glomo-checkout.js"></script>

  • Keep it inline and authorise it with a nonce, if your server already generates one per request. The same random value goes in the header and on the tag:

    <!-- Content-Security-Policy: script-src 'self' 'nonce-r4nd0m' https://unified-sdk.glomopay.com -->
<script type="module" nonce="r4nd0m">
  import { GlomoCheckoutApi } from 'https://unified-sdk.glomopay.com/index.js';
  // ...
</script>

    The nonce must be regenerated on every response. A hash ('sha256-...') also works, but breaks the moment you edit the snippet, so it is harder to keep correct. How to implement this depends on your setup:

Apache (.htaccess)
Header set Content-Security-Policy "default-src 'self'; script-src 'self' https://unified-sdk.glomopay.com; frame-src 'self' https://unified-sdk.glomopay.com https://*.glomopay.com; connect-src 'self' https://unified-sdk.glomopay.com https://*.glomopay.com; style-src 'self' 'unsafe-inline';"
Nginx
add_header Content-Security-Policy "default-src 'self'; script-src 'self' https://unified-sdk.glomopay.com; frame-src 'self' https://unified-sdk.glomopay.com https://*.glomopay.com; connect-src 'self' https://unified-sdk.glomopay.com https://*.glomopay.com; style-src 'self' 'unsafe-inline';";
Node.js/Express
app.use((req, res, next) => {
  res.setHeader(
    'Content-Security-Policy',
    "default-src 'self'; " +
      "script-src 'self' https://unified-sdk.glomopay.com; " +
      "frame-src 'self' https://unified-sdk.glomopay.com https://*.glomopay.com; " +
      "connect-src 'self' https://unified-sdk.glomopay.com https://*.glomopay.com; " +
      "style-src 'self' 'unsafe-inline';",
  );
  next();
});
Next.js (next.config.js)
module.exports = {
  async headers() {
    return [
      {
        source: '/(.*)',
        headers: [
          {
            key: 'Content-Security-Policy',
            value:
              "default-src 'self'; script-src 'self' https://unified-sdk.glomopay.com; frame-src 'self' https://unified-sdk.glomopay.com https://*.glomopay.com; connect-src 'self' https://unified-sdk.glomopay.com https://*.glomopay.com; style-src 'self' 'unsafe-inline';",
          },
        ],
      },
    ];
  },
};
ASP.NET Core (C#)

Add this middleware in Program.cs (or Startup.cs):

app.Use(async (context, next) =>
{
    context.Response.Headers.Append("Content-Security-Policy",
        "default-src 'self'; " +
        "script-src 'self' https://unified-sdk.glomopay.com; " +
        "frame-src 'self' https://unified-sdk.glomopay.com https://*.glomopay.com; " +
        "connect-src 'self' https://unified-sdk.glomopay.com https://*.glomopay.com; " +
        "style-src 'self' 'unsafe-inline';");
    await next();
});

For IIS, you can add these headers in web.config:

<configuration>
  <system.webServer>
    <httpProtocol>
      <customHeaders>
        <add name="Content-Security-Policy" value="default-src 'self'; script-src 'self' https://unified-sdk.glomopay.com; frame-src 'self' https://unified-sdk.glomopay.com https://*.glomopay.com; connect-src 'self' https://unified-sdk.glomopay.com https://*.glomopay.com; style-src 'self' 'unsafe-inline';" />
      </customHeaders>
    </httpProtocol>
  </system.webServer>
</configuration>
Django (Python)

Using django-csp middleware:

# settings.py
CSP_DEFAULT_SRC = ("'self'",)
CSP_SCRIPT_SRC = ("'self'", "https://unified-sdk.glomopay.com")
CSP_FRAME_SRC = ("'self'", "https://unified-sdk.glomopay.com", "https://*.glomopay.com")
CSP_CONNECT_SRC = ("'self'", "https://unified-sdk.glomopay.com", "https://*.glomopay.com")
CSP_STYLE_SRC = ("'self'", "'unsafe-inline'")

Or using custom middleware:

class CSPMiddleware:
    def __init__(self, get_response):
        self.get_response = get_response

    def __call__(self, request):
        response = self.get_response(request)
        response['Content-Security-Policy'] = (
            "default-src 'self'; "
            "script-src 'self' https://unified-sdk.glomopay.com; "
            "frame-src 'self' https://unified-sdk.glomopay.com https://*.glomopay.com; "
            "connect-src 'self' https://unified-sdk.glomopay.com https://*.glomopay.com; "
            "style-src 'self' 'unsafe-inline';"
        )
        return response
Ruby on Rails

Using secure_headers gem:

# config/initializers/secure_headers.rb
SecureHeaders::Configuration.default do |config|
  config.csp = {
    default_src: %w('self'),
    script_src: %w('self' https://unified-sdk.glomopay.com),
    frame_src: %w('self' https://unified-sdk.glomopay.com https://*.glomopay.com),
    connect_src: %w('self' https://unified-sdk.glomopay.com https://*.glomopay.com),
    style_src: %w('self' 'unsafe-inline')
  }
end

Or using custom middleware:

# config/application.rb
config.middleware.insert_before 0, Rack::Headers do |headers|
  headers['Content-Security-Policy'] = "default-src 'self'; script-src 'self' https://unified-sdk.glomopay.com; frame-src 'self' https://unified-sdk.glomopay.com https://*.glomopay.com; connect-src 'self' https://unified-sdk.glomopay.com https://*.glomopay.com; style-src 'self' 'unsafe-inline';"
end

Verifying the Fix

After deploying the CSP changes:

  1. Clear your browser cache (or use incognito/private mode)
  2. Reload your website
  3. Open Developer Tools → Console tab
  4. Verify there are no CSP-related errors
  5. Check Network tab → Response Headers to confirm your CSP now includes the Glomo domains
  6. Test the checkout flow again

Note: If you have an existing CSP policy, you only need to add the Glomo domains to your existing directives rather than replacing your entire policy. Make sure to merge these domains with your current configuration.

Order

Declaration Collection