← All transactions
TXN-002PAY

CentryOS commerce payments

Bringing the CentryOS payment gateway to Shopify and BigCommerce, where merchants already sell, with webhooks that can't double-credit a balance.

Account holder
GradientFi · CentryOS
Role
Senior Software Engineer, Payments
Period
Feb 2026 — Jul 2026

Context

CentryOS is a payments gateway. A gateway only matters if merchants can reach it from the places they already sell. I worked on the merchant-facing commerce integrations, dispute handling and API edge security.

Shopify: an offsite payments extension

I built the CentryOS integration as a Shopify offsite payments extension, covering the full payment-session lifecycle: initiate, redirect, resolve. Each merchant’s API credentials are stored server-side and looked up from the shop domain on every request, so no secret ever travels through the storefront.

BigCommerce: middleware, because you can’t inject code

BigCommerce doesn’t allow direct code injection at checkout, so the integration became a middleware service. It bridges the BigCommerce Orders API and CentryOS, and adds a custom Checkout SDK payment method.

Money can’t move twice

Gateways retry webhooks, and they should. But a naive handler turns every retry into a second credit on a merchant’s balance. I made webhook ingestion idempotent, so an event posts once however many times it arrives. Then I checked it the boring way: a production Postgres reconciliation against the webhook event history, which confirmed there were no duplicate postings.

Disputes and the edge

  • Dispute and chargeback reporting. Dispute counts, fees and total amounts deducted are aggregated per settlement period into notifications merchants can actually read.
  • IP whitelisting for the payments API. I wrote the spec and docs: key scoping, enforcement at the gateway edge, and how it fits into merchant onboarding.