Fix webhook signature verification for payloads containing special characters
@IamPritamAcharya ya está trabajando en esto.
Desde el 15/4/2026.
- #352 de @IamPritamAcharya — abierto
Evaluación
- Dificultad
- 3/5
- Tiempo estimado
- 1-2 días
- Aptitud para principiantes
- 65/100
Línea de trabajo
Comienza en Utils.verifyWebhookSignature e inspecciona cómo se convierten el payload String actual y el secreto del webhook antes de la verificación HMAC. Reproduce el escenario de Scala Play con payloads que contengan caracteres especiales o multibyte y, después, verifica que la entrada de bytes sin procesar y el manejo explícito de UTF-8 produzcan la firma esperada sin cambiar el comportamiento con ASCII válido.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
In certain environments, such as Scala Play 2.8/2.9, Utils.verifyWebhookSignature may return false for valid webhook requests when the payload contains special characters or multi-byte text. The issue appears to come from the SDK accepting only a String, while framework-level parsing can alter the raw request body before verification.
Problem
Utils.verifyWebhookSignature currently accepts only a String.
This issue is especially likely when a user uses a framework such as Play to read the request body into a String before passing it to the SDK, since webhook validation is safest when performed on the raw body bytes rather than a parsed or re-encoded string.
Reproduction
- Receive a Razorpay webhook containing special characters or multi-byte characters in fields such as customer name or notes.
- Parse the HTTP body as a
Stringin Scala Play. - Pass the resulting string to
Utils.verifyWebhookSignature(...). - Observe that the method returns
falseeven though the webhook is valid.
Proposed Fix
1. Add an overload that accepts raw bytes
Introduce a new method in Utils that accepts byte[] so developers can pass the raw request body directly:
public static boolean verifyWebhookSignature(byte[] payload, String expectedSignature, String webhookSecret) throws RazorpayException {
// Use raw bytes directly to avoid encoding issues
}
2. Use UTF-8 explicitly in string-based hashing
Update the existing implementation so string payloads are always converted using UTF-8:
// Current
byte[] hash = sha256_HMAC.doFinal(payload.getBytes());
// Proposed
byte[] hash = sha256_HMAC.doFinal(payload.getBytes(UTF-8));
//Similar charset as used for encoding the webhook secret to bytes
This makes the behavior deterministic across environments and avoids platform-dependent failures.
Why This Matters
Razorpay’s webhook validation flow depends on the exact payload used to generate the HMAC signature. Any transformation of the request body — including charset conversion, normalization, or parsing into a framework-specific string type — can break verification. A byte-array overload would let developers verify the webhook against the exact raw request body, which is the safest approach for cryptographic checks.
Related Reference
A similar webhook signature verification issue has already been documented here Python SDK, Issue 65, where valid webhook signatures failed to verify in real-world setups.
I am happy to submit a PR for this if the approach is approved.
- Lenguaje dominante
- Java
- Estrellas
- 75
- Forks
- 83
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Tiene una plantilla de pull request
- Sin guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de razorpay/razorpay-java
-
Document multipart serializer mislabels MIME and emits duplicate file partsPosiblemente ocupada @u7k4rs6 la tomó hace 40 días. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
razorpay/razorpay-java#365 ·
-
Fix response parsing in shaded builds and update test infrastructure for modern JDKsPosiblemente ocupada @maheshshinde9100 la tomó hace 270 días. Abierto
Dificultad 4/5 3-5 días Aptitud para principiantes 55/100
razorpay/razorpay-java#363 ·
-
Dificultad 3/5 1-2 días Aptitud para principiantes 25/100
razorpay/razorpay-java#341 ·
-
Dificultad 3/5 1-2 días Aptitud para principiantes 25/100
razorpay/razorpay-java#340 · 3 comentarios ·
-
Dificultad 4/5 3-5 días Aptitud para principiantes 38/100
razorpay/razorpay-java#337 ·
Todos los issues de razorpay/razorpay-java
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
strimzi/strimzi-kafka-operator#13328 · 1 comentario · 3 reacciones ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
GoogleContainerTools/jib#4538 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 67/100
OpenLiberty/ci.maven#2137 ·
Los mantenedores suelen responder en 1 día
-
Payer adjustment can exceed the balance left after copay and deductible, so claim payments add up to more than the chargePosiblemente ocupada @DG47 la tomó hoy. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 79/100
synthetichealth/synthea#1772 ·
Los mantenedores suelen responder en 13 días
-
bug dependencies
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100