Skip to main content
MoonPay is highly committed to security. For this reason, whenever sensitive information such as emails or wallet addresses are transmitted to the widget, you are required to use the signature parameter, otherwise the MoonPay widget fails to load. This measure makes it more difficult for unauthorized third parties to misuse the widget’s pre-fill feature. A signed URL helps limit access from unauthorized third parties by providing limited permissions and time to make a request. Passing the signature parameter is mandatory if you’re using the walletAddress or walletAddresses parameter and it must be appended at the end of the URL. If your widget URL contains sensitive information, use the signature parameter. You can generate a signature of the URL server-side and append it to the end of the URL. If the signature is provided, we’ll check the validity of the query string to make sure it has not been altered. If the signature is invalid for any reason the MoonPay widget will fail to load.

How to sign URLs

Follow these steps for signing URLs:
  1. Send your widget URL to your backend server.
  2. Generate the signature using the secret key found in your MoonPay dashboard.
    • Use your own code to generate signatures and sign URLs
    • Alternatively, use our Node SDK to generate signatures, sign URLs, and validate signatures.
  3. Return either the signature or entire signed URL.
    • If using a SDK, return the signature and use updateSignature. Do not encode the signature, as the SDK handles this.
    • If using a URL-based integration, return the entire signed URL. Make sure the value of signature and other parameters are URL-encoded.
  4. Show the widget using the SDK or URL.
Returning the signature vs entire signed URLIntegrations using an SDK: Return the signature by itself and use updateSignatureIntegrations using URLs: Return the entire signed URL

How to generate signatures

  1. Create an HMAC (Hash-Based Message Authentication Code) using the SHA-256 hash function.
    1. Use your secret API key as the key and the original URL’s query string as the message.
  2. For URL-based integrations, make sure all query parameter values are URL-encoded before creating the signature.
All query parameter values (not the entire query string) need to be URL-encoded before generating the signature for it to be valid.

Code examples

Integrations using an SDK

Integrations using a web or mobile SDK should calculate the signature, then return the signature by itself, not URL-encoded. More details about signing with each SDK:

Integrations using URLs

Integrations generating widget URLs should calculate the signature, URL-encode the signature, then return the whole signed URL.
Attention: The API gateway of some cloud providers change your parameter’s order, resulting in a failed signature validation.

Verify your implementation

Run your signing code against this fixed input and compare the output. If it matches, your implementation is correct and any remaining problem is in the URL you sign, not in your code. The signed URL is the original URL with &signature=oIJxSghyzll%2FBLhUFdQZhkxf7DAS8REFaWr%2FibO%2BK8Q%3D appended. The keys in this vector are placeholders for documentation and are not real credentials. Two details this vector checks:
  • The message includes the leading ?. If your code produces z2PF5gVnemAZat6jSnLdgG7MB9SNX1TCrRc2bkHq8DQ=, you are signing the query string without the ?.
  • This signature happens to contain +, / and =, so it also exercises the URL encoding step. Append the URL-encoded form.

Troubleshooting

Signing failures return HTTP 400 with moonPayErrorCode: 1_SYS_UNKNOWN. That code does not mean an internal error: the message field states the real cause (Invalid signature, Missing signature, Invalid API key). See Errors for why. Key rotation is safe: while two secret keys are active on your account, signatures from either key are accepted.