7.5.0

Overview

This is a minor release that only adds support for PHP 8.2 and 8.3, and allows for symfony/yaml version 7 to be used. This is to support the upcoming version of Magento 2.4.7

What's Changed

• Adds support for PHP 8.2 and 8.3 to the PHP SDK 7.x.x version
• Add support for symfony/yaml version 7

Notes

Full Changelog: 7.4.0...7.5.0

8.0.3

Overview

This is a patch update that provides the following:

• Package updates
• Test improvements
• Bug fixes

What's Changed

• Improved null and boolean assertions
• Updated dependencies
• Fixed a bug where the payoutPercentage property on BitPaySDK\Model\Settlement was a float instead of an array
• Fixed a bug where the SDK looked for "proxy" instead of "Proxy" in the config file keys

Thank you @peter279k for your contributions!

Full Changelog: 8.0.2...8.0.3

8.0.2

Overview

This is a patch update that provides the following:

• Package updates
• Documentation updates

What's Changed

• SP-626 PHPdoc - @see tag updates
• Bump phpunit/phpunit from 9.6.10 to 9.6.11

Full Changelog: 8.0.1...8.0.2

8.0.1

Overview

This is a patch update that provides the following:

• Package updates
• Auto-generated documentation
• Fixes PHP 8.0 support

Full Changelog: 8.0.0...8.0.1

8.0.0

Overview

We were releasing our next major version of the PHP SDK - version 8.0.0.

Highlights

Client Class Breakdown

The Client class was very large, at over 2,000 lines. 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 8.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 8.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 implemented PSR-12 across the entire SDK and are using PHPCS to check every commit.

Functional Test Suite

A functional test suite has been added to the codebase that will run against the test API. Due to there being so many outside variables from external resources, this does not run in the GitHub Actions pipeline.

Other Notes

• Overall improvements to approach
• Added Composer setup script for simpler token creation
• Removed phpcs exceptions
• Added strict types & copyright
• Added generated PHPDoc
• Only actively supported versions of PHP will be supported starting with this version

Bug Fixes

• Fixed an issue when getting Ledgers

7.4.0

Overview

This release adds support for Payout Groups, which are preferred over Payout Batches, which are deprecated.

What's Changed

• Added support for Payout Groups

Notes

Full Changelog: 7.3.1...7.4.0

7.3.1

Overview

This release addresses an issue with Payout Batches, which are a deprecated feature of the API but are still used by some clients.

What's Changed

• Bump symfony/yaml from 5.4.17 to 5.4.19
• Addressed an issue with PayoutBatch deserialization and maintained backwards compatibility which addresses issue #238

Notes

The main change here updates the _computeAndSetAmount() function to catch a case where it can be stdClass and is related to the use of JsonMapper. For historical reasons, the 7.x version of the API includes JsonMapper in a manual fashion, and the upcoming 8.x release includes it via Composer.

    private function _computeAndSetAmount()
    {
        $amount = 0.0;
        if ($this->_instructions) {
            foreach ($this->_instructions as $instruction) {
                if ($instruction instanceof PayoutInstruction) {
                    $amount += $instruction->getAmount();
                } elseif ($instruction instanceof \stdClass) {
                    $amount += $instruction->amount;
                } else {
                    $amount += $instruction['amount'];
                }
            }
        }
        $this->_amount = $amount;
    }

Full Changelog: 7.3.0...7.3.1

8.0.0-beta2

Overview

We were nearing a release of our next major version of the PHP SDK - version 8.0.0. This is the first beta, and includes all the major changes, with subsequent betas addressing bug fixes.

What's Changed Since beta1

• Added unit/integration tests to readme
• Overall improvements to approach
• Added Composer setup script for simpler token creation
• Removed phpcs exceptions
• Added strict types & copyright
• Added generated PHPDoc

Full Changelog: 8.0.0-beta1...8.0.0-beta2

Version 8.0.0 Highlights

Client Class Breakdown

The Client class was very large, at over 2,000 lines. To make this easier to work on and more testable, we have:

• Implemented a facade for the client
• Create a class to handle generic REST GET, PUT, POST, and DELETE
• Created separate classes for each resource, providing a better representation of the API
• Updated BitPaySetup class so that configuration and keys can be generated
• Add unit and integration tests for new client classes

Implement POS Facade

Prior to version 8.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 8.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 implemented PSR-12 across the entire SDK and are using PHPCS to check every commit. There are a few rules currently excluded via ruleset.xml, but we plan on removing as many exclusions as possible.

• Generic.NamingConventions.UpperCaseConstantName
• PSR12.Properties.ConstantVisibility.NotFound
• PSR2.Classes.PropertyDeclaration
• PSR2.Methods.MethodDeclaration.Underscore

Functional Test Suite

A functional test suite has been added to the codebase that will run against the test API. Due to there being so many outside variables from external resources, this does not run in the GitHub Actions pipeline.

Bug Fixes

• Fixed an issue when getting Ledgers

8.0.0-beta1

Overview

We were nearing a release of our next major version of the PHP SDK - version 8.0.0. This is the first beta, and includes all the major changes, with subsequent betas addressing bug fixes.

Highlights

Client Class Breakdown

The Client class was very large, at over 2,000 lines. To make this easier to work on and more testable, we have:

• Implemented a facade for the client
• Create a class to handle generic REST GET, PUT, POST, and DELETE
• Created separate classes for each resource, providing a better representation of the API
• Updated BitPaySetup class so that configuration and keys can be generated
• Add unit and integration tests for new client classes

Implement POS Facade

Prior to version 8.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 8.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 implemented PSR-12 across the entire SDK and are using PHPCS to check every commit. There are a few rules currently excluded via ruleset.xml, but we plan on removing as many exclusions as possible.

• Generic.NamingConventions.UpperCaseConstantName
• PSR12.Properties.ConstantVisibility.NotFound
• PSR2.Classes.PropertyDeclaration
• PSR2.Methods.MethodDeclaration.Underscore

Functional Test Suite

A functional test suite has been added to the codebase that will run against the test API. Due to there being so many outside variables from external resources, this does not run in the GitHub Actions pipeline.

Bug Fixes

• Fixed an issue when getting Ledgers

Full Changelog: 7.1.0...8.0.0-beta1

7.3.0

Overview

This release bumps patch versions of dependencies, adds a new method to cancel invoices by GUID, removes PHP 7.4 from the pipeline, and allows for a null selectedWallet.

Changed

• Bump phpunit/phpunit from 9.5.26 to 9.5.27 by @dependabot in #201
• Bump symfony/yaml from 5.4.14 to 5.4.17 by @dependabot in #202
• Bump phpunit/phpunit from 9.5.27 to 9.5.28 by @dependabot in #205
• SP-402 - PHP SDK 7.x: DELETE /invoices/guid/:guid by @mrevib in #203
• SP-437 - Remove PHP 7.4 from pipeline by @mrevib in #210

Fixes

• SP-453 - PHP - Allow null selectedWallet by @mrevib in #216

Notes

Regarding a null selected wallet, we addressed #212 where the following actions can result in a null value for buyerProvidedInfo.selectedWallet:

1. Create an invoice
2. Go to the invoice pay screen
3. Choose the BitPay wallet
4. Click the back link in the viewport (not the browser back button)

After step #4, buyerProvidedInfo.selectedWallet will have a null value. This resolves the crash where the SDK expected a string.

Full Changelog: 7.2.0...7.3.0