Checkout.com PHP SDK

Official PHP SDK for the Checkout.com payments API.

SDK
Composer
v5.3.0
56stars
MIT License

Repository Health

Pre-computed score based on development activity, maintenance, community, maturity, and trend momentum.How we score it →
72/100Good
Development Activity84
Maintenance84
Community48
Maturity60
Momentum12

Technical Analysis

AI-assessed by reading the actual repository — architecture, code quality, innovation, and documentation.How we score it →
76/100Good
Architecture84
Code Quality82
Innovation62
Learning Curve74

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

Search