Salir en produccion - suscripciones

[empresarrollo]

Hola! Genial que te pusiste con esto, mas commits y mejor explicacion que ML, que parece que mucho no les interesa...

Me vino genial tu implementación para ver que onda, porque tengo que hacer algo con suscripciones y manejarlo a mano desde el panel de control es un garrón

A partir de lo que tenés hecho estoy probando con postman para mandar requests a ML

Te pregunto a ver si sabés:

• Llamando a /preapproval_plan, con el access_token de TEST me dice que Test tokens are not allowed
• Llamando con el token de produccion me devuelve un plan creado perfecto (y lo veo en el panel de control de mercadopago)
• • Si entro a la URL que me devuelve de sandbox, que tiene como pre-cargadas tarjetas de prueba, al confirmar la suscripcion me da "oops, hubo un error"
• • Si entro a la URL real, y pruebo con una de las tarjetas de prueba, tambien me da "oops hubo un error" (o algo asi)

Entonces:

• Hay forma de probar lo de suscripciones sin usar una tarjeta real ?
• Debería llenar el formulario de "Quiero ir a produccion" al estar usando estas llamadas de la api?
• Si o si toda la data que devuelve debe venir por IPN? o podria venir por webhook?

Otra duda que me surgió:

• Ademas en el boton edit dentro de aplicaciones hay un Redirect URI y un Notifications Callback URL... sirven para algo eso ? Deben estar llenos esos campos?

Perdón por tantas preguntas, pero justo encontré tu repo, y parece que tenés experiencia con el tema.

Saludos!

[aaferna]

Hola @empresarrollo Gracias por tu comentario y por crear este Issue.

Te comento que en tema de suscripciones es el mas complejo de todas las herramientas.

Hace un rato me respondieron un reclamo que abrí sobre las suscripciones y textual:

Lamentablemente no es posible utilizar el modo beta de la herramienta ya que aún no se encuentra totalmente migrada a la nueva arquitectura.

A lo que refiere que las Suscripciones como las conocemos están a ahí de dejar de correr (como las usamos y conocemos mediante las herramientas de API/SDK) algo traen entre manos, te lo dejo a modo de dato.

En el mientras tanto, como indico en la WIKI, lo mejor es probarlo con casos reales, Suscripciones funciona desde 10$ (básicamente todo), para que veas que llega por IPN como reacciona el sistema.

Deduzco que los pagos van a seguir entrando por IPN si es que se renueva la herramienta, si no sera una horda de gente muy enojada la que ira a atacar a Mercado Libre, acá en GralPaz y Panamericana...

Respecto de las Tarjetas de prueba, solo me han funcionado (por completo, IPN con LINK en modo TEST), las que están en este Link

Sobre el formulario de "Ir a Produccion" es obligatorio, porque si no no podras iniciar las herramientas de cobro, de esa forma ML/MP pueden Fiscalizar para AFIP.. (Caso ARG)

Los botones de Redirect URI y Notifications CallBack URL nunca los eh usado porque los implemento desde la SDK (solo la IPN o lo que seria Notifications CallBack URL, la implemento desde aqui ya que controla TODO lo que ingresa en la cuenta y no lo que ingresa por la aplicación.

Resumen: 1) Te recomiendo usar todo en Produccion para tener pruebas Reales 2) Configura IPN desde https://www.mercadopago.com.ar/ipn-notifications 3) Ir a Producción es obligatorio para que fiscalice AFIP-MP/ML 4) Los SANDBOX solo funcionaron en mi caso con los Links, con el resto nada.

Espero haberte sido de ayuda, y si no me explique o tenes mas dudas porfavor coméntame que te respondo!

[empresarrollo]

Genial! muchas gracias por tu respuesta! Mañana seguiré con este tema, y probaré creando una suscripción de 10ars y con una tarjeta real a ver como llegan los datos a IPN

La única pregunta que me surge ahora es: ¿Básicamente hay que crear una suscripción por cliente, poniendo el ID que tenga tu cliente en tu base de datos en external_reference no? Es la única forma de saber unívocamente a qué cliente de tu sistema corresponde cada cobro y demás.

Saludos y gracias, seguro que andaré seguido por acá, y despues de que me saque estos temas de encima ayudo con PRs para irlo mejorando aun mas

[aaferna]

Hay otra forma y créeme que estuve esperando este tiempo a ver a quien se le prendía la pregunta.

Las herramientas de MP funcionan con un doble factor. El primero es el ID de la Transacción ya sea POINT, QR, Link o Suscripción,y el Segundo es el external_reference

Pero si te digo que en TODOS los casos funciona con Triple Factor o Cuádruple Factor?

• Si analizas el ID de la transacción, mediante IPN: Obtienes los datos de la venta y DEL PAGADOR
• Si analiza el ID de la Transacción, mediante API / SDK (Lo estoy Armando) Obtienes, Comprador y Pagador

Recién te dije, Cuádruple o Triple Factor.

1) Tipo de Transaccion _(recurring_payment, pos_payment, regularpayment) 2) Medio de Pago (Tarjeta, Transferencia) 3) Pagador 4) Comprador

En las Suscripciones Te llega ID de Transacción, External_reference y PAGADOR

Si vos haces que el IPN reconozca el Pagador por el documento del ID que recibís, tenes mas que solucionado Quien Pago, Como Pago, Cuanto Pago y Cuando lo hizo... Pago....

Analiza bien los IPN y veras lo que te digo, por eso INSISTO en que se pruebe con escenarios reales

Te recomiendo que crees una suscripción y asocies a la gente a esa suscripción si no vas a tener un problema de suscripciones en el panel. Usando el método que te indico lo vas a poder filtrar perfectamente.

[aaferna]

Te agradeciera la ayuda que quieras, cualquier cosa colabora ya que mi intención es hacer que este sea EL SDK para usar MP Fácil.

[aaferna]

Locura, te invito a que veas la Wiki, ya esta la parte de devoluciones https://github.com/gusgeek/SAPIDK-MercadoPago/wiki/Pagos-y-Devoluciones

[empresarrollo]

Buenas, A partir de lo que pusiste en la parte de wiki, probé lo que sería tu función responseid() de mandar un GET a /v1/payments/ID?access_token=token (con una compra que hice yo en ML, al parecer funciona para compras hechas por vos tambien).

Perfecto, veo que te devuelve todos esos datos, hasta lo que te cobra de comision ML y lo que te queda neto.

---

El tema de reconocer el Pagador/Comprador por el DNI y/o nombre que pongan al guardar la suscripción, lo veo medio dificil, porque implicaría que haga a cada persona registrada en mi plataforma que cargue esos datos y confiar en que los carguen IGUAL cuando ponen los datos de la tarjeta y demas en la suscripcion cuando entran en init_point.

Por eso la unica que veo es, cuando un usuario va a elegir un plan pago en mi web, ahi crear un nuevo preapproval_plan con un external_reference. Y ahi supongo que ese external_reference vendrá en cada payment (esto es lo que tengo que probar).

Me quedará en el panel de mercadopago un plan/suscripcion por cada cliente (espero que con mucho exito y muchos planes ahi...), pero es la única que se me ocurre. Además está el tema de que cada persona va a pagar algo distinto (hay 2 planes, y cada uno paga por usuario), así que igual no es que podría tener un plan solo y listo.

Igual como digo, tengo que ponerme a probar bien todo este tema para ver que realmente sea así.

---

Lo de ir a producción ellos chequean algo? Hay que darles un usuario de prueba o algo, o es solo una formalidad de llenar el formulario y listo?

---

Te agradeciera la ayuda que quieras, cualquier cosa colabora ya que mi intención es hacer que este sea EL SDK para usar MP Fácil.

Cuando tenga mas en claro todo este tipo de cosas y me saque un par de quilombos de encima voy a tratar de ponerme para convertirlo en un paquete que pueda ser usado con composer, y metido sin quilombo en cualquier framework (como Laravel, por ej)

[aaferna]

Hola Para ser claros, toda este SDK funciona así como explícitas por medio de la API. El mismo funcionará en mercado libre y psgo ya que todo va a mercado pago.

Respecto de las suscripciones, crear un plan por cliente es una opción si después te querés volver loco para cambiar el precio de cada plan. Al margen de eso sea por como decís vos o como te comento yo, en ambos pueden ingresar datos falsos, pero si lo hacen no pueden cobrar, por lo cual si experimentaste con este SDK para hacer suscripciones verás que el único dato que el cliente puede falsear es el mail. El resto son los datos de tarjeta de crédito. Por lo cual si cargar la tarjeta tenés el documento si comprobas que el dni de la tarjeta sea el mismo que el de tu sistema, bueno el resto es obvio. Ya se soluciona.

Lo de ir a prifuccion la verdad no te entendí pero en sus de mercado pago seguro te pueden colaborar

Y te agradezco tu ayuda con el PR, composer no me es un herramienta de interés ya que la intención de este SDK es que lo descargas aquí y lo incluyas rapido. Con composer son más pasos. Pero espero tu pr, en una de esas cambio de opinión quien sabe!!!! Un abrazo

[heinzex]

Hola Tengo la misma duda que @empresarrollo nose si esto seguira activo pero necesitaria un poco de ayuda, el problema que tengo es lo que dice él, vos respondes de que no se pueden falsear x datos, pero ese no es el problema, sino que si una persona se registra en nuestra app con x datos, y al momento de pagar utiliza una tarjeta de credito u otra cuenta ajena a los datos del registro, no habra forma de saber a quien pertenece el pago, y ahi viene el problema de como se puede saber aquien pertenece, yo tambien la unica solucion que encontre es crear una suscripcion con un external_reference distinto para cada usuario pero el hacer esto hace que despues sea una locura modificar el precio de los mismos, porque mp tampoco te deja modificar en masa segun lei en la documentacion. estaria bueno que se le pueda agregarle un parametro de referencia a la url de la suscripcion, cosa que en la documentacion no vi que se pueda hacer.