BTI-1166 - Python SDK | Update, Test & Release 0.2.0#21
Merged
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`.
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.
Updates the changelog to document the addition of the Point of Sale (POS) payment method. Also includes a minor refactor to use a `_upper_first` helper function for capitalizing group types, improving consistency and robustness in parameter handling.
![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: 2f725df233
ℹ️ 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.
When cancel() is called with an original transaction key, this now builds a request with service action Pay instead of Cancel. Real cancellation requests will either be sent as the wrong action or hit Pay-specific service-parameter validation, whereas the previous implementation explicitly used build("Cancel", validate=False) because cancellation only needs OriginalTransactionKey.
Useful? React with 👍 / 👎.
Comment on lines
+37
to
+38
| FAILED_CODES = {PAYMENT_FAILED, VALIDATION_FAILED, TECHNICAL_ERROR, REJECTED} | ||
| CANCELLED_CODES = {CANCELLED, CANCELLED_BY_CONSUMER_LATE, CANCELLED_BY_MERCHANT, CANCELLED_BY_CONSUMER} |
There was a problem hiding this comment.
For Buckaroo responses with status code 691 or 692, this change removes them from the failed set and includes them in CANCELLED_CODES, so callers now get is_failed() == False and is_cancelled() == True for rejected payments. These codes were previously named REJECTED_BY_USER and REJECTED_TECHNICAL and treated as failures, so rejection handling in client code will be skipped.
Useful? React with 👍 / 👎.
Standardize string literals to use double quotes and improve whitespace consistency throughout the codebase.
vildanbina
approved these changes
Jul 20, 2026
vildanbina
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
BTI-977 - Add payment method: Point Of Sale
BTI-27 - Python SDK | Add solution: Subscriptions