Release 6.5.0 (#386)

This release introduces comprehensive improvements to the PHP SDK's payment and processing data models, focusing on documentation clarity, alignment with API specifications, and enhanced support for accommodation and airline payment features. The changes include detailed docblocks for classes and properties, deprecation notices for outdated fields, and new or updated models for handling accommodation and airline data across different payment flows.

Documentation and Specification Alignment

• Added or improved docblocks for nearly all major payment-related classes (e.g., AccommodationData, AccommodationGuest, AccommodationRoom, Passenger, FlightLegDetails, airline data classes) to clarify their purpose and usage. [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12]
• Updated property annotations to use correct array/object types, added [Optional] markers, and provided detailed notes on API quirks, expected types, and backward compatibility. [1] [2] [3] [4] [5] [6]

Accommodation and Airline Data Enhancements

• Added new properties to AccommodationData (e.g., property_phone, customer_service_phone) and introduced the AccommodationPhone model to support richer accommodation contact details. [1] [2]
• Refined airline and accommodation data handling in processing and payment context classes, ensuring correct property names and types per API requirements (e.g., plan instead of billing_plan, ticket/passenger as objects not arrays, use of shared models). [1] [2] [3]

Deprecations and Backwards Compatibility

• Added deprecation notices for properties and classes no longer supported by the API (e.g., service_class in FlightLegDetails, PaymentContextsPartnerCustomerRiskData), with guidance on preferred alternatives. [1] [2]
• Clarified which properties are retained for backwards compatibility and which are ignored by the gateway. [1] [2]

Schema and Model Corrections

• Updated several models to use the correct local versions (e.g., PaymentSetupAccommodationAddress, PaymentSetupAccommodationRoom) where the schema differs from the main payment models. [1] [2]
• Improved handling and documentation of airline and accommodation arrays in processing settings, payment contexts, and main payment requests. [1] [2] [3]

New Models

• Introduced AccommodationPhone to encapsulate property and customer service phone details for accommodations.

These changes significantly improve the maintainability, correctness, and clarity of the SDK's payment data models, making integration with the Checkout API more predictable and robust.

Release 6.4.0 - Add verification attempt-assets endpoints and card scheduled_activation_date (#382)

⚠️ Breaking changes (see at the bottom)

This release introduces several enhancements and structural improvements to the identity verification and face authentication modules. The main updates include adding support for pagination when listing verification attempts, introducing new fields and types for richer applicant data, and enabling retrieval of document/image assets for verification attempts. The changes also improve type annotations and documentation for better clarity and extensibility.

Pagination and Asset Retrieval Enhancements:

• Added support for optional pagination (skip and limit) when listing verification attempts in the get...Attempts methods for identity, ID document, address document, and face authentication clients, using the new AttemptsQueryFilter class. These methods now use the new query method in ApiClient to handle query parameters. [1] [2] [3] [4] [5] [6]
• Introduced new API methods to retrieve uploaded document/image assets for specific verification attempts in the ID document and address document verification clients, supporting optional pagination. [1] [2]

Applicant Data Model Improvements:

• Added new entity classes: PhoneNumber, IdvAddress, IdentityDeclaredData, and IdentityVerificationClientInformation to capture richer applicant details, including phone, email, address, document issuing country, and document type. [1] [2] [3] [4]
• Updated request objects for verification attempts to support the new applicant data fields and types, and improved property annotations for clarity and validation. [1] [2] [3]

Type and Documentation Improvements:

• Improved type annotations and documentation for fields in ClientInformation, DeclaredData, and related request/response objects, specifying formats, examples, and optionality for better developer experience and validation. [1] [2]

Dependency and Import Updates:

• Added necessary imports for new classes in client and request files to support the new features and types. [1] [2] [3] [4]

These updates make the API more flexible, extensible, and user-friendly, especially for clients needing to paginate results or capture additional applicant information.

⚠️ Breaking changes

Note: nothing else is breaking. The new getXAttempts($id, ?AttemptsQueryFilter $query = null) and updateCardDetails($cardId, $request, ?CardUpdateHeaders $headers = null) parameters default to null, and ApiClient::query() was widened to accept a nullable filter. Properties are untyped, so the IdentityDeclaredData and IdentityVerificationClientInformation subclasses are a docblock change only.

Release 6.3.0 (#379)

• Add PaymentSetup accommodation/airline fields (total_number_of_guests, refundable, delivery_recipient, host, total_number_of_passengers, travel_type, trip_type, ancillaries, insurance)

Release 6.2.1 (#377)

This release updates the OAuthScope class to align with the latest API specification, removing deprecated scopes, adding new ones, and ensuring accuracy and maintainability. It also updates related integration tests to use the correct scopes and introduces a comprehensive unit test suite for OAuthScope.

OAuthScope class updates:

• Removed deprecated scopes issuing:card-mgmt and issuing:client, as well as marketplace, and replaced them with the appropriate card-management scopes. Added new scopes: compliance-requests, flow:reflow, issuing-disputes, and vault:tokens-metadata. Properties are now consistently ordered alphabetically, and documentation was improved. [1] [2] [3] [4]

Test updates:

• Updated all integration tests (AbstractIssuingIntegrationTest.php, TransactionsIntegrationTest.php, and SandboxTestFixture.php) to use the new card-management scope properties instead of the retired ones, with clarifying comments. [1] [2] [3]

New unit tests for OAuthScope:

• Added OAuthScopeTest.php to verify that all documented scopes are present, that no wire value is blank or duplicated, and that properties are declared in alphabetical order. Also includes tests to distinguish similar-looking scopes and to check for spec sync correctness.

Release 6.2.0 (#375)

This release introduces several enhancements and fixes to the balances and payments functionality, focusing on improved support for sub-account (currency account) operations, more robust query parameter handling, and expanded test coverage. Key changes include the addition of a new endpoint for retrieving top-up instructions, improvements to query parameter serialization, and new/updated tests to ensure correct API contract adherence.

Balances and Currency Account Enhancements:

• Added a retrieveTopUpInstructions method to BalancesClient, allowing retrieval of bank details and payment reference information required to top up a sub-account (currency account). This includes comprehensive documentation of the response structure. (lib/Checkout/Balances/BalancesClient.php) [1] [2]
• Introduced the balances:top-up-instructions OAuth scope to support authorization for the new endpoint. (lib/Checkout/OAuthScope.php)

Query Parameter Serialization Improvements:

• Enhanced AbstractQueryFilter::getEncodedQueryParameters() to only include set parameters, avoid trailing ampersands, and serialize booleans as "true"/"false" (not 1/0) to comply with API requirements. (lib/Checkout/Common/AbstractQueryFilter.php)
• Extended BalancesQuery to support withCurrencyAccountId (boolean) and balancesAt (datetime) parameters, with detailed documentation on naming and expected wire format. (lib/Checkout/Balances/BalancesQuery.php)

Payments API Schema Update:

• Added the amount_allocations property to PaymentSessionSubmitRequest, supporting allocation of payment amounts to sub-entities, with min/max constraints and documentation. (lib/Checkout/Payments/Sessions/PaymentSessionSubmitRequest.php)

Test Coverage and Validation:

• Added and updated unit and integration tests for:
  • Serialization of BalancesQuery parameters, ensuring camelCase keys and correct boolean/date formatting. (test/Checkout/Tests/Balances/BalancesQuerySerializationTest.php)
  • The new retrieveTopUpInstructions endpoint, including both mocked and integration tests that handle expected API error responses gracefully. (test/Checkout/Tests/Balances/BalancesClientTest.php, test/Checkout/Tests/Balances/BalancesIntegrationTest.php) [1] [2] [3] [4]
  • Serialization of amount_allocations in payment session requests. (test/Checkout/Tests/Payments/Sessions/PaymentSessionSubmitRequestSerializationTest.php)
• Updated test OAuth scopes to include the new balances:top-up-instructions permission. (test/Checkout/Tests/SandboxTestFixture.php)

These changes improve the SDK's compliance with the latest API specifications, enhance developer usability, and strengthen contract validation through comprehensive testing.

Release 6.1.0 (#372)

Breaking changes (check at the end )

This release introduces comprehensive support for Bacs and ACH Direct Debit instruments in the SDK, including new client classes, request models, and type definitions. It also updates core enums to recognize these new instrument and payment source types. The changes enable storing, configuring, and sending notifications for Bacs and ACH instruments, and ensure the SDK aligns with the latest API specifications.

Bacs Direct Debit Support:

• Added BacsClient for sending Bacs Direct Debit pre-notifications, with corresponding request and notification type classes (BacsNotificationRequest, BacsNotificationType). Also exposed getBacsClient() in CheckoutApi. [1] [2] [3] [4] [5] [6] [7]
• Introduced models for creating Bacs instruments: CreateBacsInstrumentRequest, CreateBacsInstrumentAccount, CreateBacsInstrumentData, CreateBacsAccountHolder, CreateBacsBillingAddress, and BacsPaymentType. [1] [2] [3] [4] [5] [6]

ACH Direct Debit Support:

• Added models for creating ACH instruments: CreateAchInstrumentRequest, CreateAchInstrumentData, CreateAchAccountHolder, and AchAccountType. [1] [2] [3] [4]

SEPA Direct Debit Support:

• Added CreateSepaAccountHolder for SEPA instrument account holder details.

Core Enum Updates:

• Updated InstrumentType and PaymentSourceType to include bacs and ach as valid types, reflecting new instrument and payment source options. [1] [2] [3] [4]

These changes provide the necessary models and client interfaces to support Bacs and ACH Direct Debit instruments, improve maintainability, and ensure compatibility with the current API.

Breaking changes

This release is breaking and ships as 6.0.0 (already bumped in this branch via the merged
Release 6.0.0 (#370) commit: CheckoutUtils::PROJECT_VERSION and version.json).

The instruments models were reshaped so that each scheme (SEPA, Bacs, ACH) and each operation
(store, update) has its own type. Previously a single InstrumentData and the shared
Checkout\Common\AccountHolder were reused across operations they did not match, which exposed
fields the API rejects and hid fields it requires.

Removed classes

The removed class held account_number, country, currency, payment_type, mandate_id and
date_of_signature. All six exist on the replacements, plus type (the SEPA mandate type), which
the specification declares and the old class was missing.

Retyped properties

All three are on Checkout\Instruments\Create\CreateSepaInstrumentRequest:

The $customer entry is a documentation correction rather than a runtime change: the old @var
pointed at a class that does not exist in that namespace (the real one lives in
Checkout\Instruments\Update). Static analysis will now flag callers who pass the old type.

Migration

// Before
$instrumentData = new InstrumentData();
$instrumentData->account_number = "FR7630006000011234567890189";
$instrumentData->country        = Country::$FR;
$instrumentData->currency       = Currency::$EUR;
$instrumentData->payment_type   = PaymentType::$recurring;   // sent "Recurring" - rejected

$accountHolder = new AccountHolder();
$accountHolder->first_name      = "John";
$accountHolder->last_name       = "Wick";
$accountHolder->phone           = $phone;                    // not in the SEPA schema
$accountHolder->billing_address = $address;

$request = new CreateSepaInstrumentRequest();
$request->instrument_data = $instrumentData;
$request->account_holder  = $accountHolder;

// After
$instrumentData = new CreateSepaInstrumentData();
$instrumentData->type           = SepaMandateType::$core;    // new: was missing entirely
$instrumentData->account_number = "FR7630006000011234567890189";
$instrumentData->country        = Country::$FR;
$instrumentData->currency       = Currency::$EUR;
$instrumentData->payment_type   = SepaPaymentType::$recurring;  // sends "recurring"

$billingAddress = new CreateSepaBillingAddress();
$billingAddress->address_line1 = "Evergreen Terrace";
$billingAddress->address_line2 = "742";
$billingAddress->city          = "Paris";
$billingAddress->zip           = "75000";
$billingAddress->country       = Country::$FR;

$accountHolder = new CreateSepaAccountHolder();
$accountHolder->first_name      = "John";
$accountHolder->last_name       = "Wick";
$accountHolder->billing_address = $billingAddress;

$request = new CreateSepaInstrumentRequest();
$request->instrument_data = $instrumentData;
$request->account_holder  = $accountHolder;

Release 6.0.0 (#370)

• The merchant-specific subdomain (environmentSubdomain) is now required. Set it, or call the deprecated useLegacyDomain() to keep using the shared checkout.com hosts.
• An invalid subdomain now throws instead of being silently ignored.
• Add optional amount to VoidRequest to support partial voids.
• Add the ISV (SaaS seller) payout schedule fields balance_minimum, carry_forward_enabled and payment_instrument_id.

Release 5.4.0 (#364)

• Add InstrumentDocumentType with bank_statement for bank account payment instrument documents (#360)
• Model the onboarding bank_verification, articles_of_association and shareholder_structure documents as their own classes with their own type constants, instead of the generic Document whose docblock pointed at the identity DocumentType (#361)

Release 5.3.0 (#358)

This pull request introduces several improvements and clarifications to the 3DS challenge indicator and related enums used in session and payment APIs. The main focus is on separating the values specific to session requests from those used in payment flows, improving documentation, and ensuring backwards compatibility. Additionally, related enums are updated for clarity and consistency, and comprehensive tests are added to verify correct serialization and deprecation handling.

Key changes:

3DS Challenge Indicator Improvements

• Introduced a new SessionChallengeIndicatorType class with clear documentation and nine explicit values, including exemption values, for use only with session requests (POST /sessions). This separates session-specific values from those used in payments.
• Updated ChallengeIndicatorType in Checkout\Common to clarify that five exemption values are deprecated and only accepted by sessions, not by payments or hosted payments. Documentation is improved and deprecation tags are added for these values.
• Updated SessionRequest to use SessionChallengeIndicatorType for the challenge_indicator property, with improved docblocks and default value assignment. [1] [2] [3]

Related Enum and Property Updates

• Updated Category, SessionScheme, and TransactionType enums with improved documentation, consistent naming, and added or corrected values (e.g., non_payment, quasi_card_transaction, new schemes like discover and upi). [1] [2] [3]

Test Improvements

• Added a comprehensive test class, ChallengeIndicatorSerializationTest, to verify that all challenge indicator values are exposed, correctly serialized, and properly marked as deprecated where appropriate.
• Updated integration tests to use the new SessionChallengeIndicatorType for session requests. [1] [2] [3] [4] [5]

These changes clarify the intended usage of challenge indicator values, improve maintainability, and ensure that the SDK aligns with API expectations and best practices.

Release 5.2.1 (#355)

This release adds missing fields to the RepresentativeIndividual model for the Accounts API v3.0 and updates the forward secrets endpoint path.

Accounts API v3.0 Model Additions and Updates:

• Added the Citizenship class and extended RepresentativeIndividual with the citizenships array and national_id_type fields.
• Added the NationalIdType enum covering the various types of national identification numbers.
• Added the FinancialStatements class and FinancialStatementsType enum, and updated OnboardSubEntityDocuments to use FinancialStatements for the financial_statements field.

Forward API:

• Moved the forward secret item path to /secrets/{name} (INT-1666).

Release 5.2.0 (#352)

** Accounts BREAKING CHANGE **

This release introduces significant enhancements and extensions to the Accounts API client and related data models to support Accounts API v3.0. The main goals are to enable schema version negotiation via the Accept header, expand the onboarding request and company models for new v3.0 fields, and add several new supporting classes for richer onboarding flows.

The most important changes are:

Accounts API v3.0 Schema Versioning Support: BREAKING CHANGE!

• Added a DEFAULT_SCHEMA_VERSION constant and updated key client methods in AccountsClient to accept a $schemaVersion parameter (defaulting to 3.0), passing this as an Accept header to the API. This enables negotiation of the Accounts API schema version for all major entity operations. [1] [2] [3] [4] [5]

Expanded Onboarding and Company Models:

• Extended OnboardEntityRequest and Company with new fields required by Accounts API v3.0, such as processing_details, agreed_terms, seller_category, is_draft, date_of_incorporation, regulatory_licence_number, and more. Added detailed PHPDoc for each field. [1] [2]
• Added new business types in BusinessType and new entity roles in EntityRoles for v3.0 compatibility. [1] [2]

New Supporting Data Classes for v3.0:

• Introduced new classes for richer onboarding and processing details: AgreedTerms, ProcessingDetails, ProcessingDetailsPayments, ProcessingDetailsAch, DateOfIncorporation, and CompanyPosition. These enable capturing additional information required by the latest API version. [1] [2] [3] [4] [5] [6]

OnboardSubEntityDocuments Enhancements:

• Expanded OnboardSubEntityDocuments with new optional document fields (e.g., articles_of_association, shareholder_structure, bank_verification, etc.) to support the full set of required documents for different onboarding schema variants.

Documentation and Header Handling Improvements:

• Improved PHPDoc for all updated and new fields, clarifying requirements and formats. Enhanced Headers to support the new accept header for schema negotiation.

These changes collectively prepare the codebase for full support of Accounts API v3.0 onboarding and entity management, while maintaining backward compatibility.

Release 5.1.0 (#347)

This release introduces several new features and improvements to the issuing and payments domains, including expanded support for dispute handling, enhancements to card activation and revocation scheduling, and richer order/payment setup models. It also removes some deprecated or redundant classes and fields to streamline the codebase.

Issuing Disputes Enhancements:

• Added new models for handling fraud-related dispute details (IssuingDisputeFraudDetails, IssuingDisputeFraudType) and integrated them into dispute request classes, allowing for more granular and structured fraud reporting. [1] [2] [3] [4] [5] [6]
• Introduced the AmendDisputeRequest model and corresponding amendDispute method in IssuingClient, enabling amendments to disputes that are blocked or require additional information. [1] [2] [3] [4]
• Marked the submitDispute method as deprecated, guiding users towards the new dispute amendment flow.

Card Management Improvements:

• Added activation_date and revocation_date fields to both CardRequest and UpdateCardRequest classes, allowing for scheduled card activation and automatic revocation. [1] [2]
• Removed the ScheduleRevocationRequest class and related scheduling methods from IssuingClient, consolidating revocation scheduling into the main card request models. [1] [2] [3]

Payments and Order Setup Extensions:

• Enhanced the Order model with new fields for invoice_id, shipping_amount, surcharge_amount, tax_amount, tipping_amount, and amount_allocations, supporting more detailed order breakdowns.
• Added new models for PaymentSetupAmountAllocation and AmountAllocationCommission, enabling split payments and commission handling in setup flows. [1] [2]
• Introduced the PaymentSetupBillingDescriptor model for richer payment descriptions and billing information.

Account and Instrument Details:

• Added InstrumentAccountType and InstrumentDetailsAch models to support ACH payment instrument details, including account and routing numbers. [1] [2]

Cleanup and Deprecations:

• Removed the CardholderDocument class and related references from cardholder request models, simplifying cardholder data structures. [1] [2] [3] [4]

These changes collectively improve the flexibility, compliance, and functionality of the issuing and payments APIs, while also streamlining the codebase for easier maintenance.…nd Platforms instrument details)

GetFaceAuthenticationAttemptAssets, PaymentPlan updates + Move to PHP versions 8.X (dropped all 7.X ones) (#345)

BREAKING CHANGE

This release drops support for PHP 7.1 and 7.4, raising the minimum required PHP version to 8.1. It updates the SDK and its dependencies accordingly, simplifies the Composer and CI workflows, and updates documentation to reflect these changes.

PHP version and dependency requirements:

• Updated composer.json to require php: >=8.1.0, guzzlehttp/guzzle: ^7.4, and monolog/monolog: ^2.4 || ^3.0.0; dropped support for older versions and removed compatibility with PHP 7.x and Guzzle 6.x. Updated dev dependencies to require phpunit/phpunit: ^9.0 only.
• Updated README.md to state that as of v5.0.0, the SDK requires PHP 8.1 or newer, and to explain the rationale for dropping PHP 7.x support. Updated Composer example accordingly.

Continuous Integration (CI) and workflow changes:

• Removed all references to PHP 7.1 and 7.4 from GitHub Actions workflows (build-master.yml, build-pull-request.yml, build-release.yml), so CI now only tests PHP 8.1 and 8.4 on supported OSes. Simplified installation and Composer steps accordingly. [1] [2] [3] [4] [5] [6] [7] [8]

General update

This release introduces new functionality for retrieving assets associated with face authentication and identity verification attempts, adds support for recurring payment plans and authorization types to several payment request objects, and exposes a new processing field. It also includes comprehensive tests for the new features.

Identity Verification & Face Authentication Enhancements:

• Added the AttemptAssetsQueryFilter entity to support pagination when querying assets related to authentication and verification attempts.
• Introduced getFaceAuthenticationAttemptAssets and getIdentityVerificationAttemptAssets methods in their respective clients, enabling retrieval of assets (like images and videos) captured during an attempt, with optional pagination. [1] [2]
• Added corresponding unit and integration tests for these new asset retrieval methods, ensuring correct API endpoint usage and response validation. [1] [2] [3] [4] [5] [6]

Payments API Improvements:

• Added support for recurring payment plans and authorization types by introducing new payment_plan and authorization_type fields to HostedPaymentsSessionRequest, PaymentLinkRequest, and PaymentSessionsRequest. [1] [2] [3]
• Exposed the scheme_transaction_link_id field in ProcessingSettings to allow access to the scheme transaction link identifier for card transactions.
• Updated integration tests to safely access the new scheme_transaction_link_id field, confirming its presence and type when available.

Release 4.9.0 - General payments update (#340)

This release introduces several new features and enhancements across the SDK, mainly focusing on expanding support for dispute evidence, onboarding simulation, and entity requirements, along with some smaller improvements and bug fixes. The most important changes are grouped below by theme.

Onboarding Simulator Support:

• Added a new OnboardingSimulatorClient class and related request objects, enabling sandbox testing of account onboarding workflows, such as setting requirements due, running scenarios, and updating entity status. This client is now accessible via the main CheckoutApi class. [1] [2] [3] [4] [5] [6] [7]

Entity Requirements Management:

• Enhanced the AccountsClient with methods to retrieve pending requirements for a sub-entity, get details about specific requirements, and resolve requirements with a new EntityRequirementUpdateRequest class. [1] [2] [3]

Dispute Evidence Enhancements:

• Added a CompellingEvidence model and extended the DisputeEvidenceRequest to support new fields for arbitration evidence and compelling evidence, improving dispute handling capabilities. [1] [2] [3]

Instruments Management Improvements:

• Added a revoke method to InstrumentsClient to allow revoking instruments for future transactions, and updated related request classes for clarity and expanded customer data support. [1] [2] [3] [4] [5]

Other Enhancements and Fixes:

• Added support for query parameters and body variables in DestinationRequest for forwarding requests.
• Updated the PHP 8.4 download URL in the GitHub Actions workflow for Windows builds.
• Added new fields to issuing card request classes for metadata, revocation date, and card controls. [1] [2]

These changes collectively improve the SDK's feature coverage, especially for testing onboarding flows, managing entity compliance, and dispute resolution.

Release 4.8.0 (#337)

This release adds support for a wide range of new alternative payment methods (APMs) by introducing new payment source types and corresponding request source classes. These changes enable the system to handle additional payment options such as ACH, Bizum, Blik, MobilePay, Octopus, PayNow, Plaid, Sequra, Swish, Twint, and Vipps, among others. The update primarily involves extending the PaymentSourceType enumeration and implementing new request classes for each APM, some of which include additional relevant fields.

Support for new payment source types:

• Added new static members to PaymentSourceType for various APMs, including bizum, ach, blik, mobilepay, octopus, paynow, plaid, sequra, swish, twint, and vipps.

New request source classes for APMs:

• Implemented new request source classes in the Apm namespace for each supported APM:
  • RequestAchSource, RequestBizumSource, RequestBlikSource, RequestMobilePaySource, RequestOctopusPaySource, RequestPayNowSource, RequestPlaidSource, RequestSequraSource, RequestSwishSource, RequestTwintSource, RequestVippsSource, and others. [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11]

Additional fields for specific payment sources:

• Some new request source classes include additional fields relevant to their payment method, such as account_type, country, account_number for ACH, partner_agreement_id for Blik, token and account_holder for Plaid, billing_address for Sequra, and billing_descriptor for Swish. [1] [2] [3] [4] [5]

These changes collectively expand the system's capability to support a broader array of payment methods, improving flexibility and coverage for international payments.

Version 4.7.1 (#332)

This release updates the naming conventions for request class properties in the Google Pay integration to use snake_case instead of camelCase. This change improves consistency and aligns with common PHP coding standards.

Property renaming for consistency:

Renamed properties in GooglePayEnrollmentRequest from camelCase to snake_case: entityId → entity_id, emailAddress → email_address, and acceptTermsOfService → accept_terms_of_service.
Renamed the webDomain property to web_domain in GooglePayRegisterDomainRequest.…snake-case)

Release - 4.7.0 (#330)

This release adds support for new sdk clients: Agentic Commerce, Compliance Requests and GooglePay. It introduces new API clients, request/response entity classes, and updates the main CheckoutApi class to expose these clients. Additionally, it updates the API client to allow passing custom headers for POST requests. These changes enable delegated payment token creation, compliance request retrieval, and response submission.

Agentic Commerce API integration:

• Added AgenticCommerceClient for creating delegated payment tokens, including support for custom integrity headers and idempotency keys.
• Introduced related entity classes: DelegatedPaymentRequest, DelegatedPaymentAllowance, DelegatedPaymentBillingAddress, DelegatedPaymentMethodCard, DelegatedPaymentRiskSignal, and supporting enums/types for card and funding types. [1] [2] [3] [4] [5] [6] [7] [8] [9] [10]

Compliance Requests API integration:

• Added ComplianceRequestsClient to retrieve and respond to compliance requests by payment ID.
• Added entity classes for compliance response fields and grouping by party: ComplianceRespondedField, ComplianceRespondedFields. [1] [2]

Google Pay API integration:

• Added GooglePayClient to manage all google pay enrollments and domains

Core API enhancements:

• Updated ApiClient::post to accept optional custom headers, supporting new API requirements for integrity and versioning.

Main API surface changes:

• Updated CheckoutApi to instantiate and expose AgenticCommerceClient, ComplianceRequestsClient, and GooglePayClient via new getter methods. [1] [2] [3] [4] [5]