You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jan 22, 2021. It is now read-only.
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
The text was updated successfully, but these errors were encountered:
{
"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'.
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:
Unfortunately, the request always returns the same error, even if properly configured (merchant token used, request properly signed, headers set correctly).
Request/Response dump (tokens cleared):
Response is:
Thanks in advance
The text was updated successfully, but these errors were encountered: