Checkout.com PHP SDK

Official PHP SDK for the Checkout.com payments API.

SDK
Composer
v6.4.0
56 stars
MIT License

Repository Health

Pre-computed score based on development activity, maintenance, community, maturity, and trend momentum. How we score it →
77 /100 Good
Development Activity 92
Maintenance 96
Community 48
Maturity 60
Momentum 12

Technical Analysis

AI-assessed by reading the actual repository — architecture, code quality, innovation, and documentation. How we score it →
76 /100 Good
Architecture 84
Code Quality 82
Innovation 62
Learning Curve 74

The Checkout.com PHP SDK is the official client library for integrating the Checkout.com payments platform into PHP applications. It provides a fluent, builder-based entry point that authenticates with static API keys or OAuth and exposes every Checkout.com API domain through dedicated typed clients.

Beyond core card payments (create, capture, refund, void), the SDK covers tokens and instruments, payment links and hosted pages, Apple Pay and Google Pay, disputes, customers, reconciliation reports, risk, workflows, webhooks/events, and account and issuing operations. It is built on Guzzle for HTTP, supports sandbox and production environments, and handles request signing, error mapping, and file uploads.

What You Get

  • A builder-based SDK supporting static-key and OAuth authentication
  • Payments client for create, capture, refund, and void flows
  • Clients for tokens, instruments, payment links, and hosted payments
  • Apple Pay, Google Pay, disputes, reports, risk, and webhook clients
  • Sandbox and production environment configuration

Common Use Cases

  • Accepting card and wallet payments through Checkout.com in a PHP app
  • Tokenizing and storing payment instruments for reuse
  • Handling disputes, reports, and webhook events programmatically

Under The Hood

Architecture - Entry is through builder classes (CheckoutStaticKeysSdkBuilder, CheckoutOAuthSdkBuilder, extending shared abstract builders) that assemble a CheckoutConfiguration and produce a CheckoutApi facade. CheckoutApi lazily constructs one client per API domain (PaymentsClient, TokensClient, InstrumentsClient, DisputesClient, IssuingClient, and dozens more), all built on a shared ApiClient/Client HTTP layer with a pluggable HttpClientBuilderInterface. A hierarchy of typed exceptions (CheckoutApiException, CheckoutAuthorizationException, CheckoutArgumentException) maps transport and validation failures.

Tech Stack - PHP >=8.1 built on guzzlehttp/guzzle ^7.4 for HTTP and monolog/monolog for logging, requiring the json and fileinfo extensions. Environment and subdomain enums select sandbox vs production endpoints. CI runs GitHub Actions with SonarCloud quality gating, and the package is distributed via Packagist with frequent releases.

Code Quality - The codebase is cleanly namespaced by API domain, uses a consistent client-per-domain pattern, and is gated by SonarCloud static analysis plus a full test/ suite. Active development and consistent releases (82 releases, frequent commits) indicate strong ongoing maintenance, and the pluggable HTTP client builder keeps the transport testable.

API Design - The developer experience is deliberately guided: pick a builder for your auth method, set keys and environment, build() a CheckoutApi, then call $api->getPaymentsClient()->requestPayment(...). Grouping the very large API into discrete domain clients keeps discovery manageable despite the breadth, and typed exceptions make error handling explicit. The main cost is the sheer number of clients, which lengthens the learning curve for the full platform.

Join founders buildingwith open source

Opinionated takes, migration guides, cost-saving tips, and insights from the open source ecosystem.

Subscribe on Substack
Join 750+ subscribers