Choosing a display mode

Pick the right approach — banner, custom CSS, or API — based on your requirements.

Use this guide to choose how you show discounts on your site.

Quick decision

What you need	Use	Why
Zero code, banner at top/bottom	Banner	One script tag, configure in dashboard.
Modal/full-screen surface with optional dim backdrop. Trigger on page load, delay, exit intent, or scroll depth. Optional CTA button and dismiss link	Popup	Same script tag, configured in dashboard. Paid plans only.
Static display only — country, discount %, coupon code, flag in your own layout	Custom (CSS classes)	Script fills elements by class. No JS needed.
Dynamic behavior — update checkout button URLs with `?coupon=`, show slashed price + discounted amount	API (client or server)	You need to read the data and change DOM/links; CSS classes can't do that.
No-code HTML widget (Swipepages, Webflow embed, etc.) with prices + coupon in buttons	Client API	Scoped HTML/CSS/JS in one block; no script-tag timing or builder CSS conflicts.
Server-rendered pricing, checkout, emails, mobile	Server API	You have the visitor IP; fetch discount server-side.

Static = “Show this text here.”
Example: “Get 30% off with code PPP_IN_30” and a flag. The content doesn’t change links or prices.
→ Custom mode with .ed-country, .ed-discount-amount, .ed-coupon-code, .ed-country-flag is enough.
Dynamic = “Use the discount to change something.”
Examples: set checkout link to https://checkout.example.com?coupon=PPP_IN_30, or show “$29” crossed out and “$20.30” as the real price.
→ Use the API (client or server), then update URLs and prices in your own code.

If you embed a pricing section inside a no-code builder (e.g. Swipepages, Webflow custom code, Framer embed):

Prefer the client API over the banner script. You avoid script-load timing and the builder’s global CSS affecting your layout.
Scope everything under one wrapper class (e.g. .ed-pricing-root) and prefix your CSS with that class so the builder’s styles don’t override yours.
Don’t rely on body or global resets inside the widget — the builder already controls the page. Put one <style> block and one wrapper <div> with your markup and one <script> that fetches the API and updates the DOM.

Use this guide to choose how you show discounts on your site.

What you need	Use	Why
Zero code, banner at top/bottom	Banner	One script tag, configure in dashboard.
Modal/full-screen surface with optional dim backdrop. Trigger on page load, delay, exit intent, or scroll depth. Optional CTA button and dismiss link	Popup	Same script tag, configured in dashboard. Paid plans only.
Static display only — country, discount %, coupon code, flag in your own layout	Custom (CSS classes)	Script fills elements by class. No JS needed.
Dynamic behavior — update checkout button URLs with `?coupon=`, show slashed price + discounted amount	API (client or server)	You need to read the data and change DOM/links; CSS classes can't do that.
No-code HTML widget (Swipepages, Webflow embed, etc.) with prices + coupon in buttons	Client API	Scoped HTML/CSS/JS in one block; no script-tag timing or builder CSS conflicts.
Server-rendered pricing, checkout, emails, mobile	Server API	You have the visitor IP; fetch discount server-side.

Static = “Show this text here.”
Example: “Get 30% off with code PPP_IN_30” and a flag. The content doesn’t change links or prices.
→ Custom mode with .ed-country, .ed-discount-amount, .ed-coupon-code, .ed-country-flag is enough.
Dynamic = “Use the discount to change something.”
Examples: set checkout link to https://checkout.example.com?coupon=PPP_IN_30, or show “$29” crossed out and “$20.30” as the real price.
→ Use the API (client or server), then update URLs and prices in your own code.

If you embed a pricing section inside a no-code builder (e.g. Swipepages, Webflow custom code, Framer embed):

Prefer the client API over the banner script. You avoid script-load timing and the builder’s global CSS affecting your layout.
Scope everything under one wrapper class (e.g. .ed-pricing-root) and prefix your CSS with that class so the builder’s styles don’t override yours.
Don’t rely on body or global resets inside the widget — the builder already controls the page. Put one <style> block and one wrapper <div> with your markup and one <script> that fetches the API and updates the DOM.