CoinForBarter PHP SDK

Problem

CoinForBarter merchants integrating directly against the REST API repeatedly hit the same problems: signing requests, retry logic on flaky networks, parsing webhook signatures, and writing boilerplate around charge / verify / refund flows. Each merchant was solving it on their own — slowly, inconsistently, and often incorrectly.

Approach

• 01

  Designed a small typed client surface around four verbs that mapped to merchant intent: charge, verify, refund, webhooks.

• 02

  Hid HTTP, signing, idempotency keys, and retry policy inside the SDK so merchants only think in domain terms.

• 03

  Wrote a Laravel-style facade so it slotted into existing PHP apps with one line of config.

• 04

  Shipped runnable examples for the three most common scenarios — POS, e-commerce checkout, and webhook receiver.

Outcome

• 01

  New merchant integrations went from days to hours; the SDK README is the integration guide.

• 02

  Webhook signature handling was centralised — eliminated a class of replay-attack mistakes that early integrators made.

• 03

  Bug reports dropped to almost zero because the surface area got smaller and was tested.

• 04

  Merchants who upgraded got new endpoints automatically — no support ticket queue.

Lessons

• 01

  A good SDK is a contract, not a wrapper. Design the verbs from the merchant's problem, not the API's shape.

• 02

  Idempotency, retries, and signature verification belong in the SDK, not in every merchant's integration code.

• 03

  The fastest documentation is a working example. Ship those before the prose.