What is a "unified" SDK?

📘
Note
This page is for the PHP SDK version 8.0.0 or higher. Earlier versions had a slightly different client instantiation process. For version 7.x, please see the that version's client instantiation documentation.

We previously maintained two separate SDKs for each language. The "lite" SDKs only utilized the pos facade which does not require request signing. This made it much simpler to set up because consumers of the SDKs did not have to manage key pairs, but the lite SDKs were also limited in functionality. The "full" SDKs utilized the merchant and payout facades, which have more functionality, such as creating refunds, but were inherently more complex due to signed requests requiring the consumer to generate and manage private keys.

One of the major downsides for us was upkeep. Every dependency update or new feature that would affect both SDKs would require them both to be updated. We realized that this was an unnecessary complexity and that with the right architecture, we could create a single version of each SDK that could be set up to use any of the facades.

This new unified SDK supports everything the lite and full SDKs did, all in one package. This makes it easier for consumers to start with one facade and graduate to the more complex ones with little effort. On our side, it de-duplicates the work that's going into everything and allows us to focus on continuously improving the set of SDKs.

Setup

📘
Note
This setup is required for using the merchant and payout facades. You can skip this section if If you will only be using the pos facade.

Each client paired with the BitPay server requires a ECDSA key. This key provides the security mechanism for all client interaction with the BitPay server. The public key is used to derive the specific client identity that is displayed on your BitPay dashboard. The public key is also used for securely signing all API requests from the client. See the BitPay API for more information.

The private key should be stored in the client environment such that it cannot be compromised. If your private key is compromised you should revoke the compromised client identity from the BitPay server and re-pair your client, see the API tokens for more information.

Generating a configuration and private key

Using the BitPay setup script helps to generate the private key, as well as a environment file formatted in JSON which contains all configuration requirements, that should be stored in the client local file system. It is not recommended to transmit the private key over any public or unsecure networks.

First, download an SDK ZIP from https://github.com/bitpay/php-bitpay-client-v2/releases and unpack.

Next, install the dependencies:

composer install

Finally, run the setup script:

composer run setup

Usage

First, you'll need to add the package to your project:

composer require bitpay/sdk

There are two new methods of instantiation, which is the main part of existing applications that will need to be updated.

POS Facade

If you have only the need for a simple invoice creation flow, you may want to use the pos facade which, while limited in capability, is easier to get started with because you don't need to maintain private keys.

Prerequisites

You will need to create a Point-of-Sale token in the BitPay dashboard.

Initialization

use BitPaySDK\PosClient;


$client = new PosClient("myPosToken");

Merchant/Payout Facades

In the case that you have a more complex flow that uses enhanced functionality such as refunds, you will want to use the merchant and/or payout facades.

Prerequisites

Copy the output from the setup script to a location on your system that your project can reach.

Initialization

use \BitPaySDK\Client;

// Note: Use the JSON or YML config file
$client = Client::createWithFile("/path/to/config/file")

use \BitPaySDK\Client;

$tokens = new Tokens("merchantKey", "payoutKey");

$client = Client::createWithData("prod", "myPrivateKey", $tokens, "myPrivateKeySecret");

use \BitPaySDK\Client;

$client = new  Client($restCli, Tokens $tokens);