Integration Guide - Testing


In this section, learn how to test your requests before you send them to Uber, use the Sandbox testing environment, and perform production testing.

Sandbox testing

This environment resembles production as much as possible. You test your integration on this environment. Your scenario functions similar to how they work in a production environment except accounts are test accounts.

You should make requests to the Sandbox and testing environments to:

Sandbox deposit

This endpoint initializes a deposit and calls the partner init-deposit endpoint. It generates a deposit URL. It is for testing only and Uber refuses any request on the production environment. The endpoint you call is: POST /v1/payments/deposits/:id/init

Sandbox authentication

The sandbox public key is the following:

-----END PUBLIC KEY-----

See the Signature validation section for more details.

Path parameters

Name Type Description
id UUID Deposit ID


Name Type Description
funding_method String The payment method used to fund this deposit
country_iso2 String The country in which this deposit is created — ISO3166
destination <Object> Should be left empty for this request
amount <Object> Value of currency, ISO4217. The value is in E5 format (x * 100000). For example, 10 BRL is: {"value": 1000000, "currency": "BRL"}
locale String Locale is used for the UI experience

Example request

You should leave the destination field in the request empty, and Uber inserts a test user value. You can use the example below and replace $token with the API key, and replace $id with a new, generated UUID.

curl -X POST \
  -H "Authorization: Bearer $token" \
  -H 'Content-Type: application/json' \
  -d '{
    "funding_method": "BOLETO",
    "country_iso2": "BR",
    "destination": {},
    "amount": {
      "value": 100000,
      "currency": "BRL"
    "locale": "pt-BR"

The following is an example response to the example request:

    "deposit_url": ""

Signature validation

This is how an init-deposit request from Uber looks like:

curl -X POST \ \
  -H 'Accept-Language: pt-BR' \
  -H 'Date: Sat, 08 Jun 2019 20:51:35 GMT' \
  -H 'Digest: SHA-256=YSBHoalsyyGKflQVxab5PvyRhpB+PzZ18iSWIaX5vtY==' \
  -H 'Signature: keyId="rsa-key", algorithm="rsa-sha256",
     headers="(request-target) host date digest",
  -H 'X-Correlation-ID: c900d4dd-7070-4e0b-9323-8f24cfde0490' \
  -H 'Content-Type: application/json' \
  -d '{"funding_method":"BOLETO","destination":{"owner_id":"105b9291-6ff1-4938-899e-4bfafa69a6c7","id":"cHBfNjFhN2QyODktZmI3Mi00YzgxLThlYjAtODRlZDIyMjFmNDNi"},"source":{"owner_id":"a66b36d5-887c-4e7c-9edb-9fcbef108e83","id":"Z3NfYTE0OGQ5MzMtOGVkMS00MzA0LThiNzAtNTE0MjMyMzg2MjQw"},"amount":{"value":100000,"currency":"BRL"},"country_iso2":"BR","description":"I’m a deposit in sandbox.","session_id":"8b31b7f4-3542-4391-817c-d496ce84a7ae","initiated_at":"2019-06-08T20:51:35Z","return_url":"uber://payments/deposit?correlation_id=c900d4dd-7070-4e0b-9323-8f24cfde0490"}'

You can test your requests before you send them to Uber with the OpenSSL cmd-line. For example:

openssl dgst -sha256 -verify {PUBLIC_KEY_FILE} -signature {SIGNATURE_FILE} {DECODED_HEADERS_FILE}
  • PUBLIC_KEY_FILE: Public key file
  • SIGNATURE_FILE: File containing only the signature of the header, base64 decoded. For the above example, this file contains the result of the command.

For example, the SIGNATURE_FILE looks like this:

echo bclwlUnUAE4IqMf7J/4GcgD32YMusPt0VkfM9AQX6MHKWf+59VRrNMZuyTzlmgUYzi5m79jONfReHqG/2dj99NkobwoT4XcZp2gWNrlIz2dpsyY0Nt3adOXThfAd2vDYXJtHsscKHBd5+f78GZQl3vCS3f2Wm0PiOZfqAr01YwGzpRVie0IcuWI7BEKd/fwjbaCPJc40Yax4grnA7O676T32e3qjRR0nwvg+jR2lzoIEYfg6dLHooGZdagl9riVPMO0c92GVf/48RWLZZd1mZQcfBxxDRwRaWRo10LQ+Mb/4p6aeLm9ilzafGL5ZJ8JiANETotq0eJSHNI2A0V+7uQ== | base64 -D
  • DECODED_HEADERS_FILE: File containing headers that are being used to form the signature text, for the example above the file looks like this:
(request-target): post /v1/payments/init-deposit
date: Sat, 08 Jun 2019 20:51:35 GMT
digest: SHA-256=YSBHoalsyyGKflQVxab5PvyRhpB+PzZ18iSWIaX5vtY=

Note that for the openssl validation command to work, do not provide a line ending character at the end of DECODED_HEADERS_FILE or SIGNATURE_FILE.

You should only include :{PORT} in case of non-standard ports for the given scheme as we show in the example above. For example, since port 443 is the default port for the https scheme, we don’t include it in the resulting host header text in the above example with URL If the URL is, then you should provide the host header with

We perform signature validation based on the order of the header items are important for the signature validation. Therefore, you should provide it as (request-target), host, date, digest.

Production testing

When you launch the app or service for your customers, integrate with this environment.You are responsible for any money the system deposits into customer accounts when you call this API in production. Do not share production API keys. Follow the security best practices in dealing with the production environment and when you handle all the associated data including the API key.

© 2023 Uber Technologies Inc.