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
![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
Here are some automated review suggestions for this pull request.
Reviewed commit: 149a5fd108
ℹ️ 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".
| @@ -641,36 +644,3 @@ def _post_transaction(self, request_data: Dict[str, Any]) -> PaymentResponse: | |||
| # passed when present so it stays a no-op for every other request. | |||
| extra = {"culture": self._culture} if self._culture else {} | |||
| response = self._client.http_client.post("/json/transaction", request_data, **extra) | |||
There was a problem hiding this comment.
Any payment path that calls _post_transaction (pay, refund, capture, authorize, etc.) now falls through after the HTTP POST and returns None, so callers cannot inspect the gateway response and existing tests such as test_pay_posts_to_transaction_and_returns_payment_response fail with AttributeError. Restore the previous PaymentResponse(response.to_dict())/empty-response handling or delegate this method to the new executor.
Useful? React with 👍 / 👎.
| 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.
When cancel(...) is called with a transaction key, this constructs a keyed request using action Pay and then removes the amounts, so the posted service is Action: Pay plus OriginalTransactionKey instead of a cancel request. In the cancel flow this will not cancel the pending/authorized transaction; build the keyed request with Cancel here as the base implementation did.
Useful? React with 👍 / 👎.
| CANCELLED_BY_MERCHANT = 691 | ||
| CANCELLED_BY_CONSUMER = 692 | ||
|
|
||
| # Cancelled | ||
| CANCELLED = 890 | ||
| CANCELLED_BY_CONSUMER_LATE = 891 |
There was a problem hiding this comment.
Buckaroo's status documentation lists 890 as Cancelled by User and 891 as Cancelled by Merchant (https://docs.buckaroo.io/docs/integration-status), but this change assigns CANCELLED_BY_MERCHANT to 691 and exposes 891 as CANCELLED_BY_CONSUMER_LATE. Any caller comparing against BuckarooStatusCode.CANCELLED_BY_MERCHANT will now check/send 691 instead of the documented 891, and CANCELLED_CODES also starts classifying 691/692 as cancellations.
Useful? React with 👍 / 👎.
| with open(os.path.join(ROOT_DIR, "buckaroo", "_version.py"), encoding="utf-8") as f: | ||
| exec(f.read(), version_contents) | ||
|
|
||
| version_match = re.search(r'^VERSION\s*=\s*["\']([^"\']+)["\']', f.read(), re.MULTILINE) |
There was a problem hiding this comment.
Executing setup.py in a normal packaging environment now reaches this re.search(...) call before setup() runs, but re is never imported, so source installs and metadata generation fail with NameError. Add the missing import (or avoid the regex) so the package can still be built/installed from source.
Useful? React with 👍 / 👎.
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. ```
3 participants
No description provided.