The getPublicKeyFromPrivateKey() method is calling generate($privateKey) but there's no parameter for that function call in any of the method definitions. The getSinFromPublicKey() method is incomplete. $digits should be initialized before use. $seq is dead. In verifySignature() the $contract parameter isn't being used as well as the $publicKey parameter. $P is an array but the doubleAndAdd method requires it to be a Point object. $p_hex is a string and not a CurveParameterInterface sub-type. $Q is an array and not a Point object. The calls to doubleAndAdd and gmpPoint add have too many parameters.

When creating a merchant token using the SDK, the API returns a pairing code which cannot be currently retrieved. It requires a getter to retrieve the pairing code from the API.

Response from the API is as follows.

{
  "policies": [
    {
      "policy": "id",
      "method": "inactive",
      "params": [
        "XXXXXXXXXXXXXXXXXXXX"
      ]
    }
  ],
  "token": "XXXXXXXXXXXXXXXXXXXXXXXXX",
  "facade": "merchant",
  "label": "Pairing Token",
  "dateCreated": 1418045657805,
  "pairingExpiration": 1418132057805,
  "pairingCode": "2d2daqs"
}

Also, https://github.com/bitpay/php-bitpay-client/blob/master/src/Bitpay/Client/Client.php#L489 throws a warning because the response does not contain the resource parameter.

To issue invoice refunds, I need to get the invoice resource token, but there are no methods for it.
And also please check the following lines on Client::getInvoice setToken is commented. Why?

• There are no tests (Really? This is a payment library and there are no tests?)
• Why is there a .htaccess file in a php client?
• No composer
• No autolading
• Lots of random functions
• Globals? Really?
• Classes?
• A JSON fallback option is not job of this library (who doesn't have json?)

Please deprecate it and direct people toward something like https://github.com/symm/guzzle-bitpay

This really does not make your company look good. I was considering switching to you guys from Coinbase, but that is 100% not happening now that i see the standard of your coding. I hate to think what your internal code is like.

Line 66: The return type of return false is incompatible with the return type declared by the interface Symfony\Component\DependencyInjection\Extension\ExtensionInterface::getXsdValidationBasePath of type string.

How can I use the "Settlements" resource with this library?
https://bitpay.com/api#resource-Settlements

Thanks.

In the docs (https://bitpay.com/docs/invoice-states), we have the information that exceptionState can be any of:

• false:
  The invoice is not in an exception state.
• paidPartial:
  If the amount paid is less than the amount expected then the invoice is marked as being partially paid.
• paidOver:
  If the amount paid is greater than the amount expected then the invoice is marked as being overpaid.
• paidLate:
  The invoice was paid outside the 15-minute payment window.

But in the invoice class we have this: https://github.com/bitpay/php-bitpay-client/blob/master/src/Bitpay/Invoice.php#L647

Hey, I've taken a look at composer.json and saw that this library supports PHP >= 5.4, do you have any other library that supports php 5.3?

Should the regular expression be avoided and we use the standard checking using php. The regular expression was giving errors for price=0.10 (claiming price must be formatted as a float) and after my modification it worked. Can you please check on this and get a fix.
/**
* @param float $price
*
* @return ItemInterface
_/
public function setPrice($price)
{
/_if (1 !== preg_match('/^[0-9]+(?:.[0-9]{1,2})?$/', $price)) {
throw new \Bitpay\Client\ArgumentException("Price must be formatted as a float");
}*/

    if(!is_numeric($price)){ //check if price is number
         throw new \Bitpay\Client\ArgumentException("Price is not a valid number");
    }

    if(!is_float($price)){ //check if price is float
        throw new \Bitpay\Client\ArgumentException("Price must be formatted as a float");
    }

    if(floatval($price) < 0.000006){
         throw new \Bitpay\Client\ArgumentException("Price must be minmum 0.00006 BTC");
    }

    $this->price = $price;

    return $this;
}

I tried the example found here which unfortunately result in an error using testnet.

{"error":"This endpoint does not support the `pos` facade"}

The request looks as follows

POST https://test.bitpay.com:443/payouts HTTP/1.1
...
{"token":"__REPLACED__","amount":10,"currency":"USD","instructions":[{"label":"Test","address":"__REPLACED__","amount":10}],"effectiveDate":"2015-05-29T14:05:38.000Z","pricingMethod":"bitcoinbestbuy","guid":"__REPLACED__","nonce":__REPLACED__,"reference":"123","notificationURL":"__REPLACED__"}

Note: REPLACED was placed by me to not disclose private information.

The following code is dead and can be removed:

PrivateKey.php, sign() function:
$a_hex = '0x'.Secp256k1::A;
$p_hex = '0x'.Secp256k1::P;
$Ry_hex = Util::encodeHex($R->getY());
$Ry_hex = str_pad($Ry_hex, 64, '0', STR_PAD_LEFT);

PrivateKey.php, pemEncode() function:
$seq = '';
$decoded = '';

BitAuth.php, verifySignature() function:
$a_hex = '0x'.Secp256k1::A;
$p_hex = '0x'.Secp256k1::P;
$Zy_hex = Util::encodeHex($Z->getY());
while (strlen($Zy_hex) < 64) {
$Zy_hex = '0'.$Zy_hex;
}

Gmp.php, doubleAndAdd() function:
if (null === $parameters) {
$parameters = new Secp256k1();
}

Gmp.php, gmpPointDouble() function:
$st2 = gmp_mul($m, $n2);
$s2 = gmp_mod($st2, $p);

Gmp.php, gmpPointAdd() function:
$a = '0x'.Secp256k1::A;
In the $R array, 's' => 0
$R['s'] = gmp_strval($s);

I've tried the example GetTokens.php, but it returns NULL. I have at least one token in my account.

@todo add way to configure curl with options

The generateSin() method needs to be looked at again from a OO design standpoint and probably refactored: The setPrivateKey() method doesn't exist in KeyInterface but does exists in the PublicKey implementation of the interface. Whereas the setPublicKey() method doesn't exist in KeyInterface either but does exist in the SinKey implementation of the interface. So we have one interface all three of these classes are implementing but we have methods that only exist in three concrete implementations of this one interface. We should code against the interface instead of coding against concrete implementations of the interface.

Also, $digits should be initialized before use, $seq appears to be dead and $a_hex & $p_hex appear to be dead...

For performance reasons, function calls inside loops should be avoided. These instances can be refactored:

Response.php, line 60
Base58.php, lines 43, 61, 69
Util.php, line 176

In the createFromRawResponse() method, two variables appear to be dead code in lines 82 & 84:

$version = $statusLine[1];
$statusTest = $statusLine[3];

These aren't being used anywhere in the method and could be leftover from a previous version. Or if they are important, nothing is being done with them.

The NodeJS Client names their private and public keys "api.key" and "api.pub" by default.
The PHP Client uses "api.key" and "api.pub" in the documentation on Pairing.
The PHP Client uses "bitpay.key" and "bitpay.pub" by default.

Either the documentation should be updated to use the default naming for ease of understanding, or preferably we should rename the PHP Client defaults so either language's client library can load the keys without configuring their paths.

Need some validation to ensure any unserialized objects are correct. Per the PHP docs:

"Warning: Do not pass untrusted user input to unserialize(). Unserialization can result in code being loaded and executed due to object instantiation and autoloading, and a malicious user may be able to exploit this. Use a safe, standard data interchange format such as JSON (via json_decode() and json_encode()) if you need to pass serialized data to the user."

Lines 76 & 89: The return type of false is incompatible with the return type documented by Bitpay\Crypto\OpenSSLExtension::generateKeypair of type array.

PHP Warning:  call_user_func_array() expects parameter 1 to be a valid callback, class 'Bitpay\Client\Client' does not have a method 'setContainer' in ./vendor/symfony/dependency-injection/Symfony/Component/DependencyInjection/ContainerBuilder.php on line 1131

CreateInvoice now requires that a network object is instantiated and set on the client instead of setting it in the lib's config.

A small number of merchants are receiving the exception message "Class\That\Implements\StorageInterface" does not implement "Bitpay\Storage\StorageInterface" see https://github.com/bitpay/php-bitpay-client/blob/master/src/Bitpay/Config/Configuration.php#L90 because they do not meet the requirement of PHP >= 5.3.7

Suggest that this code block is refactored and updated using http://php.net/manual/en/function.class-implements.php which can be used for merchants who have PHP >= 5.1.0

The doubleAndAdd() method seems to have been refactored to the point where the $parameters method param, $p and $a are all dead. $S could also be of type string or PointInterface. $s2 seems to be dead and that scares me for dead code to be in that area... $a is dead in the point adding method. The catch() sections need to be corrected to \Exception or whatever we're doing to use there... $digits should be initialized before use in the Binconv method. $seq is dead in the Binconv method as well, it looks like.

Have a parameter to set the X-BitPay-Plugin-Info header, so that this can be included into each plugin/integration without needing to change it.

See title. Sam assigned to the task (will add him as soon as he approved the email invitation to our GH team).

There are places throughout the codebase where code was copied in from other classes and still have the die() statements. There are also TODO comments in the code indicating where exceptions need to be thrown.

It would be nice to be able to include this library using composer. Optionally published on http://packagist.org, this way it is easier to adopt / include in existing projects.

The current Math class doesn't generate public keys correctly everytime.
The public key's y value was being set to 0 by the encodeHex function due to getting a negative y value from the R variable.

In the Item class, the property $price is declared to be of type string:

/* @var string
*/
protected $price;

But the parameter for the function setPrice() is indicated to be of type float:

/* @param float $price
@return ItemInterface
*/
public function setPrice($price)
{
$this->price = $price;

return $this;

}

In Client.php, "@$value" and "@$data" are used. Values should be properly checked before usage.

I have generated my private, public and sin keys according to the documentation, and added their respective paths to my yaml config file.
I can load the main bitpay class fine, however I cannot initialize the client class, as I receive the following error:
PHP warning: gmp_cmp(): Unable to convert variable to GMP - string is not an integer in /home/vagrant/laravel/vendor/bitpay/php-client/src/Bitpay/Math/GmpEngine.php on line 26

Any ideas?

Have Private Key generate on instantiation
Add Public Key constructor that accepts Private Key object or hex and generates itself.
Add SIN constructor that accepts Public Key object or hex and generates itself.

Refund functionality would be very nice. You may check the commit you referenced in another ticket abishekrsrikaanth/php-bitpay-client@2a981e7.

GMP classes ported to BC. Does not include native implementation yet. Library will need to be modified a bit to more generically handle math operations and pass off to correct math class, i.e. strategy pattern implemented.

hi,

i want to know how to withdraw or deposit bit coin to someones wallet address with php bitpay api

In Bill.php, $archived is declared to be of type string by used as a boolean in the constructor and set methods.

When trying to create an invoice, if BitPay responds with an error message, the client throws an exception, but replaces with specific message with "Error with request":
https://github.com/bitpay/php-bitpay-client/blob/master/src/Bitpay/Client/Client.php#L160

This makes it difficult to diagnose the actual error that is occuring, whether it be malformed data from the client, or issues with the merchant's account at BitPay.

The exception should contain the actual message from BitPay since an exception message is not a message to an end-user/customer and can be masked later on.

Needs to be changed to accept higher precision for currencies with more than 2 digits after the decimal point (like BTC)

Also, the DocBlock states that the parameter should be a float, not a string. When floats are converted to strings with other locale settings, they can use commas instead of periods as the decimal point. We need to change this so that price is actually a float, and when it is added to an invoice, it gets set correctly with the right formatting.

As the new version 2.2.4 was published some hours ago I try to fetch it with php composer.phar update but its not showing any new updates. Thats how my composer.json looks like:

{
    "require": {
        "bitpay/php-client": "dev-master"
    }
}

I've read through the documentation and have been unable to find how to use an Invoice with multiple items. I'm not sure if it's API support or just the library.

I understand that Bills will allow multiple items, but it appears the Invoices will not. While using a bill seems like a good idea, there is no notification for the payment of the bill.

Assuming the item count of the invoice must be one:
How can I mock the behavior of an invoice with a bill ( including notifications and point of sale data)?
Can we attach a bill to an Invoice?

OpenSSLExtension.php, line 100, Exception class missing ""
KeyManager.php, line 17, @var parameter missing ""
Gmp.php, line 208, Exception class missing ""

Line 152: The property $exchangePercentageFee was declared of type double, but trim($fee) is of type string.

Line 163: The return type of return $this->payoutEnabled; (boolean) is incompatible with the return type declared by the interface Bitpay\CurrencyInterface::isPayoutEnabled of type string.

Line 229: The return type of return $this->alts; (array) is incompatible with the return type declared by the interface Bitpay\CurrencyInterface::getAlts of type string.

Line 240: It seems like trim($alts) of type string is incompatible with the declared type array of property $alts.

Line 251: The return type of return $this->payoutFields; (array) is incompatible with the return type declared by the interface Bitpay\CurrencyInterface::getPayoutFields of type string.

Submit patch for mcrypt fix.

When running the pairing code, I keep getting the following error as soon as $client = $bitpay->get('client'); is called, no matter what I try:

Fatal error: Uncaught exception 'Exception' with message
'Could not decode key' in src/Bitpay/Storage/EncryptedFilesystemStorage.php on line 76

Call Stack:
    0.0002     227984   1. {main}() /my/local/path/bitpay/pairing.php:0
    0.0569    2601336   2. Bitpay\Bitpay->get() /my/local/path/bitpay/pairing.php:24
    0.0569    2601600   3. Symfony\Component\DependencyInjection\ContainerBuilder->get() /my/local/path/bitpay/php-client/src/Bitpay/Bitpay.php:132

<?php
//pairing.php

require __DIR__.'/php-client/vendor/autoload.php';

$storageEngine = new \Bitpay\Storage\EncryptedFilesystemStorage('mySecretPassword');
$privateKey    = $storageEngine->load('bitpay.pri');
$publicKey     = $storageEngine->load('bitpay.pub');

$bitpay = new \Bitpay\Bitpay(
    array(
        'bitpay' => array(
            'network'     => 'livenet',
            'public_key'  => 'bitpay.pub',
            'private_key' => 'bitpay.pri',
        )
    )
);

$client = $bitpay->get('client');

Simply persisting and loading the keys by EncryptedFilesystemStorage works fine.

For the BCMath engine, bcscale needs to be called in order to prevent it from returning numeric strings that fail its input validation.

This library should support invoice adjustments (for accepting overpayments and underpayments) but looks like this hasn't been implemented yet?

The keys must be able to be exported in an industry standard format.

The following break statements are not needed and can be refactored:

Error.php, handler() function:
Breaks on lines 105, 108, 117, 120