Conversation
…1.0.0 - Introduce a cleaner inheritance model with `BaseBuilder` and `PaymentBuilder`. - Decouple transaction execution from builders via a new `TransactionExecutor` service. - Implement `TransactionContext` to handle follow-up operations (refund, capture, cancel) explicitly instead of relying on internal payload state. - Standardize method naming to PEP 8 snake_case across all builders and capability mixins. - Enhance the HTTP client with better error wrapping, logging, and FIPS-compliant MD5 hashing. - Add GitHub Actions CI, a formal changelog, and modernized packaging metadata for the v1.0.0 release.
Adds comprehensive example scripts for Credit Card, iDEAL, In3, and PayPal. These examples demonstrate standard integration flows, including encrypted card data, Hosted Fields, two-step authorization/capture, recurring payments, and refunds.
Removes the example for paying with a pre-selected bank issuer and renames the generic payment example to `example_pay`. This streamlines the demonstration to focus on the standard flow where Buckaroo handles bank selection.
…mprehensive test suite - Apply Ruff formatting and linting rules across the entire project for consistency. - Complete the builder implementation for several payment methods, including iDEAL QR, Payconiq, and SEPA Direct Debit. - Introduce a robust testing suite comprising unit and feature tests with high coverage. - Update CI/CD workflows to support Python 3.13 and automate linting/formatting checks. - Remove redundant transaction service logic in favor of internal builder dispatching. - Add .gitattributes to ensure consistent line endings across platforms.
- Rename `BuckarooAppConfig` to `BuckarooConfig` and improve configuration handling. - Transition from snake_case to camelCase for public builder methods (e.g., `payEncrypted`, `cancelAuthorize`) to align with Buckaroo API naming conventions. - Introduce `TransactionExecutor` to centralize API communication, removing direct HTTP concerns from builders. - Simplify follow-up operations (refund, capture, cancel) by passing transaction keys directly instead of requiring a `TransactionContext` object. - Standardize status code grouping and enhance sensitive field masking in logs. - Refine error messages and validation logic within the builder hierarchy.
- Replaces `.execute()` with `.pay()` for more intuitive transaction initiation in builders and examples. - Removes the `TransactionContext` model, allowing direct passing of `original_transaction_key` and other parameters for operations like `capture`, `refund`, and `cancelAuthorize`. - Standardizes method naming from `cancel_authorize` to `cancelAuthorize` to align with camelCase conventions.
Release v0.1.1
Ensures BaseBuilder gracefully handles null HTTP responses from the API client.
refactor: Isolate payment lifecycle methods in PaymentBuilder ``` Moves payment-specific transaction methods (`pay`, `refund`, `partial_refund`, `pay_remainder`, `cancel`) from `BaseBuilder` to `PaymentBuilder`. This refactors the builder hierarchy to clearly separate generic builder functionality from operations specific to payment processing flows. `BaseBuilder` now exclusively houses common operations like `build` and `capture`, while `PaymentBuilder` encapsulates all payment lifecycle actions. ```
Introduces support for in-store PIN-based payments processed via physical terminals. This change adds a `PosBuilder` for initiating POS transactions, including specific handling for its unique characteristics: no redirect flow, immediate pending response, and delivery of the final result (with printable receipt) via push notification. A new `Channel` field is added to `BaseBuilder` and `PaymentRequest` to accommodate the fixed "Web" channel required for POS payments, which is enforced internally by the `PosBuilder`.
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Restore combine() for supplementary services
Removing the public combine() method leaves _combined_services unreachable; existing Marketplaces flows call payments.create_payment(...).combine(mp).pay() / .refund(), so they now raise AttributeError before making a request (reproduced with tests/feature/solutions/test_marketplaces.py). Please keep the method on BaseBuilder/PaymentBuilder or provide an equivalent public path so supplementary services can be added to the ServiceList.
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if not txn_key: | ||
| raise ValueError("Transaction key is required for cancel") | ||
|
|
||
| request_data = self._build_keyed_request('Pay', txn_key) |
There was a problem hiding this comment.
In cancellation flows that supply a transaction key, this builds the service as Action: Pay; the code then only removes amounts, so the gateway receives a Pay action instead of Cancel (confirmed by recording a transfer cancel request). This causes real cancellations to fail or be treated as a different operation; build Cancel here instead of Pay.
Useful? React with 👍 / 👎.
| VALIDATION_FAILED = 491 | ||
| TECHNICAL_ERROR = 492 | ||
| REJECTED = 690 | ||
| CANCELLED_BY_MERCHANT = 691 |
There was a problem hiding this comment.
For merchant-cancelled transactions, BuckarooStatusCode.CANCELLED_BY_MERCHANT now has value 691, while Buckaroo's status guide lists 891 as cancelled by merchant (https://docs.buckaroo.io/docs/integration-status). Callers comparing response.status.code.code == BuckarooStatusCode.CANCELLED_BY_MERCHANT will miss real merchant cancellations, so this constant should remain mapped to 891.
Useful? React with 👍 / 👎.
Introduces a 'combine' method to BaseBuilder, allowing CombinableServices (e.g., Marketplace Splits) to append their services to the primary payment request. This simplifies the creation of complex payment structures.
3 participants
No description provided.