Putting loyalty inside the surface merchants already use

Context

A loyalty platform is only as good as its reach. Dobare’s merchants run their stores on WordPress and WooCommerce, and asking them to bolt on a separate system is friction that loses adoption. The win condition was to make loyalty appear inside the surface merchants already use to run their business — their own storefront and admin.

Constraints

• Someone else’s runtime. A public WordPress plugin runs on installations I don’t control, against unknown theme and plugin combinations.
• The local ecosystem has its own conventions. Iranian WooCommerce stores commonly authenticate with phone-OTP plugins, and onboarding had to fit that reality rather than fight it.
• Non-technical operators. Merchants are shopkeepers, not developers — configuration has to be obvious.

Approach

I built a public WordPress / WooCommerce plugin in PHP with Composer for dependency management. Store actions connect to the Dobare loyalty API through REST controllers, and merchants drop loyalty into their storefront with a Gutenberg block — no template editing required. To fit the local market, the onboarding path integrates with the Iranian phone-OTP plugins merchants already run, so signing a customer into loyalty reuses the identity flow the store already has.

  [Dobare platform API]
         ▲
         │  REST · webhook
         │
  ┌──────┴──────────────────┐
  │  WooCommerce plugin     │
  │  REST controllers       │
  │  Gutenberg block        │
  │  OTP auth bridge        │
  └─────────────────────────┘
         │
  merchant storefront
  (theme + plugins I don't control)

Decision — Gutenberg block over a shortcode or theme edits. Shortcodes are the path of least resistance for the developer and the worst experience for the merchant. A native block makes loyalty a drag-and-drop element in the editor the merchant already uses, which is the difference between “I’ll set it up later” and a store that’s live.

Decision — integrate with existing OTP plugins, don’t reinvent identity. Shipping my own auth would have been cleaner in isolation and wrong in context. Meeting merchants on the OTP plugins they already trust removed the biggest onboarding objection.

Outcome

The plugin connects ~300 active merchant sites to the Dobare platform, putting loyalty workflows directly inside each merchant’s existing commerce surface. Running on installations I don’t control kept me honest about backward compatibility and defensive API design.

What I’d revisit

Supporting an unknown universe of themes and plugins is a long tail of compatibility edge cases. I’d put more weight up front into an automated compatibility matrix — exercising the plugin against the most common theme/plugin combinations — so regressions surface in CI rather than in a merchant’s support ticket.