Checkout.com PHP SDK
Official PHP SDK for the Checkout.com payments API.
Repository Health
Technical Analysis
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.