6.0.2

Overview

This is a patch release that addresses a type issue with satoshisPerByte where it was defined as an int but is coming back from the API as a float. We've also updated the examples to remove .value on the facade as it's not necessary.

What's Changed

• Fix satoshisPerByte
• Remove '.value' from examples

Full Changelog: 6.0.1...6.0.2

6.0.1

Overview

This is a patch release that fixes a small issue to allows a POS client to be created with either create_client() or create_pos_client(). Currently, passing in a config to create_client() will work, but this PR makes it easier to use create_pos_client() directly by passing a POS token.

Full Changelog: 6.0.0...6.0.1

5.0.5

Overview

This is a patch release that fixes a small issue to allows a POS client to be created with either create_client() or create_pos_client(). Currently, passing in a config to create_client() will work, but this PR makes it easier to use create_pos_client() directly by passing a POS token.

Full Changelog: 5.0.4...5.0.5

6.0.0

Overview

Note: ⚠️ denotes breaking changes

This is a major version that provides numerous enhancements, such as:

• Examples in the codebase
• ⚠️ More consistent exceptions
• ⚠️ Better integration with custom loggers
• ⚠️ General improvements to align with the API

Examples in the Codebase

There are new examples in the codebase to show how the SDK can be used for various scenarios:

• Logging
  • Using a custom logger with the SDK
• Bills (Merchant Facade)
  • Creating a bill
  • Getting a bill
  • Updating a bill
  • Delivering a bill via email
• Invoices (Merchant Facade)
  • Creating an invoice
  • Getting an invoice
  • Updating an invoice
  • Canceling an invoice
  • Requesting an invoice notification
• Ledgers (Merchant Facade)
  • Getting ledgers
  • Getting ledger entries
• Refunds (Merchant Facade)
  • Creating a refund
  • Updating a refund
  • Getting a refund
  • Canceling a refund
  • Request a refund notification to be resent
• Settlements (Merchant Facade)
  • Getting a settlement reconciliation report
• Payouts (Payout Facade)
  • Creating a payout
  • Getting a payout
  • Canceling a payout
  • Requesting a payout webhook to be resent
  • Requesting payout notifications
• Recipients (Payout Facade)
  • Invite payout recipients
  • Get payout recipients
  • Update payout recipients
  • Remove payout recipients
• Bills (POS Facade)
  • Creating a bill
  • Getting a bill
  • Delivering a bill
• Invoices (POS Facade)
  • Creating an invoice
  • Getting an invoice
• Rates (Public Facade)
  • Get rates for a cryptocurrency
  • Get cryptocurrency / fiat currency pair rates
• Wallets (Public Facade)
  • Get supported wallets

⚠️ More Consistent Exceptions

We have removed the old exception classes that added a tremendous amount of duplication across the SDK in favor of parsing the errors from the API. This makes the SDK less opinionated and relies on the API to inform consumers what happened, providing more consistency between the SDK and API. The result is that response messages and codes in exceptions thrown by the SDK will be 1:1 with API.

⚠️ Better Integration with Custom Loggers

You can now use your own logging framework using the new logger provider, giving more control over how logs are handled.

⚠️ General Improvements

• Updated dependencies
• Updated field types where they were misaligned with the API
• Added fields to the SDK that were missing
• Removed fields that are no longer in the API

Full Changelog: 5.0.4...6.0.0

5.0.4

Overview

This is a patch version to the SDK that addresses Pydantic validation for invoice refund addresses.

Full Changelog: 5.0.3...5.0.4

5.0.3

Overview

This is a patch version to the SDK that updates dependencies.

All Changes

• Python dependency updates
  • Update pydantic to 2.6.1
  • Update black to 24.1.1
  • Update pytest to 8.0.0
  • Update mypy to 1.8.0

Full Changelog: 5.0.2...5.0.3

5.0.2

Overview

This is a patch version to the SDK that updates dependencies.

All Changes

• Python dependency updates
  • Update pydantic to 2.5.2
  • Update black to 23.11.0
  • Update pytest to 7.4.3
  • Update mypy to 1.7.1
  • Update pytest-mypy-plugins to 3.0.0

Full Changelog: 5.0.1...5.0.2

5.0.1

Overview

This is a major revision to the SDK that implements Pydantic.

Major Changes

Pydantic helped reduce the amount of boilerplate code, especially around setters and getters, and introduces type validation.

All Changes

• Update black to v23.7.0
• Update mypy, requests, pytest-mock, pytest
• SP-655 Python SDK - pyproject.toml
• SP-673 GitHub Actions - Python throws error on tomli
• SP-685 Python - Implement Pydantic

Full Changelog: 4.0.1...5.0.0

4.0.1

Overview

This is a patch release with small updates and release automation.

What's Changed

• Updated the setup script to be able to use existing keys
• Generated config JSON is now formatted

Full Changelog: 4.0.0...4.0.1

4.0.0

Overview

We were releasing our next major version of the Python SDK - version 4.0.0.

Highlights

Client Class Breakdown

To make this easier to work on and more testable, we have:

• Implemented a facade for the client
• Created a class to handle generic REST GET, PUT, POST, and DELETE
• Created separate classes for each resource, providing a better representation of the API
• Add unit and integration tests for new client classes

Implement POS Facade

Prior to version 4.0.0, we had two separate SDKs, the "Light" SDK, which could only use the POS facade, and the "Full" SDK, which used the merchant and payout facades. This created the need for additional effort both in maintaining and implementing the SDK.

As of version 4.0.0, the SDK supports both methods. You can use just the POS facade, which is limited in feature set but does not require signed requests (no private key to manage) or with the merchant/payout facade, which has more functionality but is more complex to implement.

This provides an easier upgrade path and reduces the duplicate work of maintaining two separate SDKs regarding dependency upgrades, bug fixes, etc.

Standardization

We've are implementing PEP 8 across the entire SDK and are using Black to check every commit.

Test Suites

We have implemented functional and unit test suites to the API, and the unit tests run in GitHub Actions for all commits and pull requests.

Other Notes

• Black, Mypy, and unit tests run on Python 3.8, 3.9, 3.10, and 3.11 in the pipeline
• The SDK is now at parity with the API

Full Changelog: v3.4.2203...4.0.0