Refunds - This endpoint does not support the merchant facade

[andreground]

According to REST API docs, we should be able to get a list of all the (eventual) refunds connected to an invoice using the following method:

GET /invoices/:invoiceId/refunds
Returns the status of all refunds on an invoice.
Parameters  none
Facades     merchant

Unfortunately, the request always returns the same error, even if properly configured (merchant token used, request properly signed, headers set correctly).

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

Request/Response dump (tokens cleared):

Preparing request to https://test.bitpay.com/invoices/FV5ppbJbLsurQS49xxxxxx/refunds?token=mybeautifulmerchanttoken
* Enable automatic URL encoding
* Enable SSL validation
* Enable cookie sending with jar of 2 cookies
* Found bundle for host test.bitpay.com: 0x7fb49843a570 [can pipeline]
* Re-using existing connection! (#0) with host test.bitpay.com
* Connected to test.bitpay.com (104.20.104.39) port 443 (#0)
> GET /invoices/FV5ppbJbLsurQS49xxxxxx/refunds?token=mybeautifulmerchanttoken HTTP/1.1
> Host: test.bitpay.com
> User-Agent: insomnia/5.3.6
> Accept: */*
> Accept-Encoding: deflate, gzip
> Cookie: connect.sid=s%3Ap3514ROJEWMWEyzzIUJ2TSlBpGF4P7lI.DsOQCBnl6VTxFqD9MOKYAa7RhPiNzdsX1LGKLPESbYc; __cfduid=d3191f39dad70158e5eb0684f12bfdf6a1497906362
> x-identity: 02b8e34a199753691b4af76f2fedf6f09f9d720a2812546c8960a6d32b84xxxxxx
> x-signature: 3045022100e37f03b0318e7955e8b8f6c82ae5e069c8e3b1f608f5011fc0570f8cee9d242702204e22251d8a79d57a232317fa951e31ec9eb82f5735a2bdc9f08a2e5e33xxxxxx
> content-type: application/json
> x-accept-version: 2.0.0
< HTTP/1.1 401 Unauthorized
< Date: Mon, 19 Jun 2017 21:16:34 GMT
< Content-Type: application/json; charset=utf-8
< Content-Length: 64
< Connection: keep-alive
< Strict-Transport-Security: max-age=31536000
< X-Download-Options: noopen
< X-Content-Type-Options: nosniff
< Access-Control-Allow-Origin: *
< Access-Control-Allow-Methods: HEAD,GET,POST,PUT,DELETE,OPTIONS
< Access-Control-Allow-Headers: Content-Type,Authorization,Content-Length,X-Requested-With,Cache-Control,X-Accept-Version,x-signature,x-pubkey,x-identity,cf-connecting-ip
< ETag: W/"40-9c979e5c"
< Server: cloudflare-nginx
< CF-RAY: 371982994c1a3dc5-MXP

* Received 64 B chunk
* Curl_http_done: called premature == 0
* Connection #0 to host test.bitpay.com left intact

Response is:

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

Thanks in advance

[cjr-roland]

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

It does work but the token architecture is a bit more complex.

Essentially there are 2 types of token:

• API token: That's the one you obtained during the initial pairing process, for a specific facade (in this case 'merchant')
• resource token: this one is derived based on a resource created (an invoice for instance) and the API token used to create this resource. This token is returned in the response request to the invoice creation (you can always fetch it via a GET to invoices/invoiceId).

So in order to initiate a refund, you need 2 calls. For the adjustments/refunds call, you need to fetch first the resource token derived for a specific invoice when sending the POST request (see getInvoice() function on /src/Bitpay/Client/Client.php)

It's the same approach with all resources. For instance if you want to get the report to do the reconciliation for a specific bank settlements (GET/settlements/:settlementId/reconciliationReport) you need to fetch first the token created for the specific 'settlementId'.