Completed
Add payment link id or url in payments to be able to quickly find the link that was used
egor-shchukin@tripleten.com 2 days ago
💡 Feature request
Completed
Add payment link id or url in payments to be able to quickly find the link that was used
egor-shchukin@tripleten.com 2 days ago
💡 Feature request
Completed
Enable payment link search by link id
Currently if we need to find a specific link in, we need to search by their title. Searching by link id or by full link would enable faster search on the dashboard
egor-shchukin@tripleten.com 2 days ago
💡 Feature request
Completed
Enable payment link search by link id
Currently if we need to find a specific link in, we need to search by their title. Searching by link id or by full link would enable faster search on the dashboard
egor-shchukin@tripleten.com 2 days ago
💡 Feature request
API about invoices
Hello, As part of our development, we would need to be able to access invoices to show them on our platform. We only see the option to send them via email automatically, but we'd like to access them via the API or receive them via webhooks so we can show the to the consumers later on. Is there a way to achieve this? Thanks in advance!
Josefina Urquiza 14 days ago
💡 Feature request
API about invoices
Hello, As part of our development, we would need to be able to access invoices to show them on our platform. We only see the option to send them via email automatically, but we'd like to access them via the API or receive them via webhooks so we can show the to the consumers later on. Is there a way to achieve this? Thanks in advance!
Josefina Urquiza 14 days ago
💡 Feature request
Planned
Add usage analytics page for each created payment link to see who & when it was used
This feature exists in Stripe and seriously helps us find undocumented payments from different emails in case customers claim that they paid, but we can’t find the payment
egor-shchukin@tripleten.com 18 days ago
💡 Feature request
Planned
Add usage analytics page for each created payment link to see who & when it was used
This feature exists in Stripe and seriously helps us find undocumented payments from different emails in case customers claim that they paid, but we can’t find the payment
egor-shchukin@tripleten.com 18 days ago
💡 Feature request
Reveal detailed error code in dashboard
Hi! Currently we can only see generic reason of failure in the dashboard (Rejected by the card issuing bank. Ask the user to try later or use another method.). It would help us to also see errorStatusDetail (do_not_honor) in the dashboard to give more detailed explanations to our customers
egor-shchukin@tripleten.com 25 days ago
💡 Feature request
Reveal detailed error code in dashboard
Hi! Currently we can only see generic reason of failure in the dashboard (Rejected by the card issuing bank. Ask the user to try later or use another method.). It would help us to also see errorStatusDetail (do_not_honor) in the dashboard to give more detailed explanations to our customers
egor-shchukin@tripleten.com 25 days ago
💡 Feature request
Integration with the Meta Conversions API (CAPI) or Pixel at Checkout
Hi, team! It would be great if you could add direct integration with Meta’s Conversions API (CAPI) and the Pixel on the checkout screens. These days, it’s very difficult to track campaigns effectively using just the browser. Plus, with Meta’s new algorithm (Meta Andromeda), the system absolutely needs clean data from the server to understand who’s actually making purchases. Without this, the algorithm is working blindly, and it’s nearly impossible to scale sales profitably. Being able to send purchase events (especially via CAPI from server to server) isn’t a luxury—it’s a key necessity for any business that uses paid traffic today. The benefit? We all win: If we merchants can properly feed Meta’s algorithm, we’ll sell a lot more. And as we sell more, Rebill will naturally process a much higher volume of payments. I hope they can add this to the roadmap soon! It would be a huge win.
victor about 2 months ago
💡 Feature request
Integration with the Meta Conversions API (CAPI) or Pixel at Checkout
Hi, team! It would be great if you could add direct integration with Meta’s Conversions API (CAPI) and the Pixel on the checkout screens. These days, it’s very difficult to track campaigns effectively using just the browser. Plus, with Meta’s new algorithm (Meta Andromeda), the system absolutely needs clean data from the server to understand who’s actually making purchases. Without this, the algorithm is working blindly, and it’s nearly impossible to scale sales profitably. Being able to send purchase events (especially via CAPI from server to server) isn’t a luxury—it’s a key necessity for any business that uses paid traffic today. The benefit? We all win: If we merchants can properly feed Meta’s algorithm, we’ll sell a lot more. And as we sell more, Rebill will naturally process a much higher volume of payments. I hope they can add this to the roadmap soon! It would be a huge win.
victor about 2 months ago
💡 Feature request
Planned
DISPUTES/Counterclaims
We request visibility and follow-up on each case so that we can know its status at all times: whether it is still being processed, or whether it was resolved in favor of the buyer or in favor of the company.
rominapaulli@msklatam.com 2 months ago
💡 Feature request
Planned
DISPUTES/Counterclaims
We request visibility and follow-up on each case so that we can know its status at all times: whether it is still being processed, or whether it was resolved in favor of the buyer or in favor of the company.
rominapaulli@msklatam.com 2 months ago
💡 Feature request
Ability to set up payment schedule for subscriptions
We would love to have an ability to set up uneven charges with a specific customizable date of next payment. Example: 1st payment: 18000 MXN 2nd payment: 3500 MXN, +26 days 3rd payment: 3500 MXN, next month 4th payment: 3500 MXN, next month Currently we have to use product + plan mix to be able to provide such option
egor-shchukin@tripleten.com 2 months ago
💡 Feature request
Ability to set up payment schedule for subscriptions
We would love to have an ability to set up uneven charges with a specific customizable date of next payment. Example: 1st payment: 18000 MXN 2nd payment: 3500 MXN, +26 days 3rd payment: 3500 MXN, next month 4th payment: 3500 MXN, next month Currently we have to use product + plan mix to be able to provide such option
egor-shchukin@tripleten.com 2 months ago
💡 Feature request
Problem with webhook
Good afternoon, I'm not receiving the subscription events for Make. Here's the link to the webhook. Best regards. https://hook.us2.make.com/twuxiqib5veksvuixm5s1bythuhtpudp
Leandro Bustingorry 2 months ago
💡 Feature request
Problem with webhook
Good afternoon, I'm not receiving the subscription events for Make. Here's the link to the webhook. Best regards. https://hook.us2.make.com/twuxiqib5veksvuixm5s1bythuhtpudp
Leandro Bustingorry 2 months ago
💡 Feature request
Add the event of chargeback into dashboard and ability to sort by it
Currently if we check chargebacks in the new dashboard, they are all linked to the original payment date and we don’t even know when they were initiated. As a result, we don’t know which ones we can counterdispute and which ones we can’t
egor-shchukin@tripleten.com 3 months ago
💡 Feature request
Add the event of chargeback into dashboard and ability to sort by it
Currently if we check chargebacks in the new dashboard, they are all linked to the original payment date and we don’t even know when they were initiated. As a result, we don’t know which ones we can counterdispute and which ones we can’t
egor-shchukin@tripleten.com 3 months ago
💡 Feature request
Sugerencias de mejoras operativas
Incrementar la cantidad de reintentos de cobro, sumando 3 adicionales, para alcanzar un total de 7 intentos. Permitir la activación y el cobro manual mientras la operación se encuentra en estado “reintentando”, sin necesidad de esperar 48 horas. Esto resulta clave especialmente el último día del mes, ya que el alumno puede informar que ya percibió sus haberes y está en condiciones de abonar. De esta forma, se evita considerarlo como no recuperado dentro del mes vigente y mejora el porcentaje de recupero. Reducir la longitud del link de cambio de tarjeta, para facilitar su uso y envío. Simplificar los campos del link de pago, eliminando la obligatoriedad de completar domicilio y código postal. Incorporar la visualización del tipo de tarjeta en la plataforma (crédito, débito o prepaga).
rominapaulli@msklatam.com 3 months ago
💡 Feature request
Sugerencias de mejoras operativas
Incrementar la cantidad de reintentos de cobro, sumando 3 adicionales, para alcanzar un total de 7 intentos. Permitir la activación y el cobro manual mientras la operación se encuentra en estado “reintentando”, sin necesidad de esperar 48 horas. Esto resulta clave especialmente el último día del mes, ya que el alumno puede informar que ya percibió sus haberes y está en condiciones de abonar. De esta forma, se evita considerarlo como no recuperado dentro del mes vigente y mejora el porcentaje de recupero. Reducir la longitud del link de cambio de tarjeta, para facilitar su uso y envío. Simplificar los campos del link de pago, eliminando la obligatoriedad de completar domicilio y código postal. Incorporar la visualización del tipo de tarjeta en la plataforma (crédito, débito o prepaga).
rominapaulli@msklatam.com 3 months ago
💡 Feature request
Documentation and MCP Server for LLM
Hi, how are you? I think you have a great solution, but it’s very difficult for an LLM to process your developer page. I don't mean to name the competition, but Mercado Libre has three things you could add: Documentation in .md format An MCP server for the documentation An AI chatbot for inquiries (once the MCP server is up and running, this would be the natural next step) I hope you find my recommendation helpful. Best regards!!
Miguel Ovejero 3 months ago
💡 Feature request
Documentation and MCP Server for LLM
Hi, how are you? I think you have a great solution, but it’s very difficult for an LLM to process your developer page. I don't mean to name the competition, but Mercado Libre has three things you could add: Documentation in .md format An MCP server for the documentation An AI chatbot for inquiries (once the MCP server is up and running, this would be the natural next step) I hope you find my recommendation helpful. Best regards!!
Miguel Ovejero 3 months ago
💡 Feature request
Completed
Webhooks de producción rechazados con 401
Hola equipo! Necesitamos ayuda para diagnosticar la autenticación de webhooks en producción, porque las requests entrantes no están alineando con el esquema de seguridad documentado. Contexto: Endpoint: https://mercantis.io/api/rebill/webhook Content-Type procesado: application/json Implementamos validación HMAC SHA-256 según docs (x-rebill-signature + secreto compartido) También probamos allowlist de IPs (34.225.22.63, 3.221.139.192) Comportamiento observado: Las requests entrantes no incluyen x-rebill-signature (ni headers equivalentes de firma) IP de origen observada en logs: 52.158.209.200 (fuera de la allowlist documentada) Resultado: 401 en el 100% de los intentos (no es intermitente) Importante: Esta integración venía funcionando correctamente. No rotamos API keys ni cambiamos la URL del webhook. ¿Nos pueden confirmar el contrato de autenticación vigente para webhooks en producción? Si lo necesitan, podemos compartir request IDs y timestamps exactos de entregas fallidas.
Lucas Nasich 3 months ago
📥 Feedback
Completed
Webhooks de producción rechazados con 401
Hola equipo! Necesitamos ayuda para diagnosticar la autenticación de webhooks en producción, porque las requests entrantes no están alineando con el esquema de seguridad documentado. Contexto: Endpoint: https://mercantis.io/api/rebill/webhook Content-Type procesado: application/json Implementamos validación HMAC SHA-256 según docs (x-rebill-signature + secreto compartido) También probamos allowlist de IPs (34.225.22.63, 3.221.139.192) Comportamiento observado: Las requests entrantes no incluyen x-rebill-signature (ni headers equivalentes de firma) IP de origen observada en logs: 52.158.209.200 (fuera de la allowlist documentada) Resultado: 401 en el 100% de los intentos (no es intermitente) Importante: Esta integración venía funcionando correctamente. No rotamos API keys ni cambiamos la URL del webhook. ¿Nos pueden confirmar el contrato de autenticación vigente para webhooks en producción? Si lo necesitan, podemos compartir request IDs y timestamps exactos de entregas fallidas.
Lucas Nasich 3 months ago
📥 Feedback
Webhooks de producción rechazados con 401.
Hola equipo! Necesitamos ayuda para diagnosticar la autenticación de webhooks en producción, porque las requests entrantes no están alineando con el esquema de seguridad documentado. Contexto: Endpoint: https://mercantis.io/api/rebill/webhook Content-Type procesado: application/json Implementamos validación HMAC SHA-256 según docs (x-rebill-signature + secreto compartido) También probamos allowlist de IPs (34.225.22.63, 3.221.139.192) Comportamiento observado: Las requests entrantes no incluyen x-rebill-signature (ni headers equivalentes de firma) IP de origen observada en logs: 52.158.209.200 (fuera de la allowlist documentada) Resultado: 401 en el 100% de los intentos (no es intermitente) Importante: Esta integración venía funcionando correctamente. No rotamos API keys ni cambiamos la URL del webhook. ¿Nos pueden confirmar el contrato de autenticación vigente para webhooks en producción? Si lo necesitan, podemos compartir request IDs y timestamps exactos de entregas fallidas.
Lucas Nasich 3 months ago
📥 Feedback
Webhooks de producción rechazados con 401.
Hola equipo! Necesitamos ayuda para diagnosticar la autenticación de webhooks en producción, porque las requests entrantes no están alineando con el esquema de seguridad documentado. Contexto: Endpoint: https://mercantis.io/api/rebill/webhook Content-Type procesado: application/json Implementamos validación HMAC SHA-256 según docs (x-rebill-signature + secreto compartido) También probamos allowlist de IPs (34.225.22.63, 3.221.139.192) Comportamiento observado: Las requests entrantes no incluyen x-rebill-signature (ni headers equivalentes de firma) IP de origen observada en logs: 52.158.209.200 (fuera de la allowlist documentada) Resultado: 401 en el 100% de los intentos (no es intermitente) Importante: Esta integración venía funcionando correctamente. No rotamos API keys ni cambiamos la URL del webhook. ¿Nos pueden confirmar el contrato de autenticación vigente para webhooks en producción? Si lo necesitan, podemos compartir request IDs y timestamps exactos de entregas fallidas.
Lucas Nasich 3 months ago
📥 Feedback
Segundo método de Verificacion
Buenos dias, estaría bueno que se implemente un segundo método de verificación cuando se intenta abrir la cuenta en un dispositivo nuevo. Actualmente solo con la clave ya se puede ingresar en cualquier computadora. Un app de autenticación, SMS o mail, si es mas de uno mejor. Saludos.
Leandro Bustingorry 3 months ago
💡 Feature request
Segundo método de Verificacion
Buenos dias, estaría bueno que se implemente un segundo método de verificación cuando se intenta abrir la cuenta en un dispositivo nuevo. Actualmente solo con la clave ya se puede ingresar en cualquier computadora. Un app de autenticación, SMS o mail, si es mas de uno mejor. Saludos.
Leandro Bustingorry 3 months ago
💡 Feature request
Rejected
enviar webhook notifications por mail
Si un cliente se da de baja, no se le cobró, u ocurre otro escenario, como comercio quiero estar al tanto y no depender de los webhooks. Si tan solo pudiesen enviar un mail sería ideal para estar al tanto
Ariel Lipschutz 4 months ago
💡 Feature request
Rejected
enviar webhook notifications por mail
Si un cliente se da de baja, no se le cobró, u ocurre otro escenario, como comercio quiero estar al tanto y no depender de los webhooks. Si tan solo pudiesen enviar un mail sería ideal para estar al tanto
Ariel Lipschutz 4 months ago
💡 Feature request
Rejected
Usar Rebill con cuenta personal
A la hora de crear cuenta, el sistema pide ingresar un mail corporativo. Estaria bueno que el producto esté disponible para personas físicas.
Tadeo Maddonni 4 months ago
💡 Feature request
Rejected
Usar Rebill con cuenta personal
A la hora de crear cuenta, el sistema pide ingresar un mail corporativo. Estaria bueno que el producto esté disponible para personas físicas.
Tadeo Maddonni 4 months ago
💡 Feature request
Completed
Modificar DNI / CUIT de clientes
En Argentina, a veces es necesario cambiar la razón social junto al DNI / CUIT de los clientes cuando estos pasan de categoría a responsables inscriptos, o desean cambiar la suscripción a ser cobrada a una empresa. Es importante poder realizar esta modificación desde el dashboard sin pedir que se suscriban nuevamente, ya que esto agrega una fricción innecesaria. Pd: ¡Muchas gracias por el productazo que están construyendo!
Matias Sifres 4 months ago
💡 Feature request
Completed
Modificar DNI / CUIT de clientes
En Argentina, a veces es necesario cambiar la razón social junto al DNI / CUIT de los clientes cuando estos pasan de categoría a responsables inscriptos, o desean cambiar la suscripción a ser cobrada a una empresa. Es importante poder realizar esta modificación desde el dashboard sin pedir que se suscriban nuevamente, ya que esto agrega una fricción innecesaria. Pd: ¡Muchas gracias por el productazo que están construyendo!
Matias Sifres 4 months ago
💡 Feature request
Completed
Link creation, transaction pages revert back to vanilla state & 1st page
Every time there’s a change on the page - for example, we extend it to check earlier links, when we open it & go back - page reverts back to original state. Example:
egor-shchukin@tripleten.com 4 months ago
💡 Feature request
Completed
Link creation, transaction pages revert back to vanilla state & 1st page
Every time there’s a change on the page - for example, we extend it to check earlier links, when we open it & go back - page reverts back to original state. Example:
egor-shchukin@tripleten.com 4 months ago
💡 Feature request