Saltearse al contenido

Elegir método de pago

INGALCA Pay tiene tres proveedores hoy: transferencia bancaria, Dinelco y Bancard. Dinelco se puede usar de dos formas distintas: con un iframe que el cliente completa en cada compra (checkout one-shot), o catastrando la tarjeta una vez y cobrando después con el token guardado. Bancard, por ahora, ofrece el checkout de pago ocasional (el cliente tipea la tarjeta dentro del iframe en cada compra). Esta página resume cuándo conviene cada combinación.

Comparativa rápida

TransferenciaDinelco — checkoutDinelco — catastro + tokenBancard — checkout
Qué hace tu cliente en cada compraTransfiere desde su home banking y sube el comprobanteTipea la tarjeta dentro del iframe + 3DSCatastra la tarjeta la primera vez; en las compras siguientes, elige la guardada y autoriza el cobroTipea la tarjeta dentro del iframe (3DS lo maneja Bancard)
Donde vive la UXTu UI + nuestra APIIframe Dinelco embebido en tu UITu UI; el iframe aparece solo en el catastro inicialIframe Bancard embebido en tu UI (proxeado por nosotros)
Cuándo se confirmaCuando tu operador aprueba el comprobante (manual)Segundos, sincrónicoSegundos, sincrónicoAl recibir la confirmación de Bancard (callback), típicamente segundos
Reversa por APINo automatizableSí, antes del corte de liquidación del díaSí, antes del corteSí, el mismo día (antes de la liquidación/cuponada)
Catastro previo del clienteNoNoSí — POST /v1/cards una vez por tarjetaNo (tarjetas guardadas: fase futura)
3DS / OTP del clienteN/ASí, en cada compraSí en el catastro inicialSí, dentro del iframe de Bancard
MonedaPYGPYGPYGPYG
Apto para montos grandes (B2B, mayoreo)Sí — es el caso típicoLimitado al tope de la tarjeta del clienteLimitado al tope de la tarjetaLimitado al tope de la tarjeta

Cuándo usar cada uno

Transferencia bancaria

  • Pagos de monto alto donde la tarjeta puede no alcanzar (B2B, mayoristas, servicios profesionales).
  • Clientes que prefieren pagar desde su home banking, o que no usan tarjeta.
  • Estás de acuerdo con que haya un humano (tu operador) en el medio para revisar el comprobante.

→ Guía completa: Pago por transferencia.

Dinelco — checkout

  • E-commerce de cobro único, ticket online, evento puntual, donación.
  • Cliente no necesariamente recurrente, o no querés guardarle la tarjeta.
  • Necesitás confirmación inmediata (orden web, número de ticket, acceso a contenido, etc.).

→ Es el flujo por defecto cuando usás provider=dinelco en POST /v1/payments.

Dinelco — catastro + token

  • Tu cliente vuelve a comprar y querés bajarle la fricción en cada compra siguiente — que no retipee los 16 dígitos, la fecha y el CVV otra vez.
  • Casos típicos: tiendas con clientes recurrentes, recompra rápida (“pagar con la tarjeta de siempre” en un click).

→ Guía completa: Pago con tarjeta tokenizada.

Bancard — checkout

  • E-commerce de cobro único con tarjeta, igual que el checkout de Dinelco, pero procesado por Bancard.
  • El cliente tipea la tarjeta dentro del iframe de Bancard (embebido en tu UI vía el checkout_url que te devolvemos); el 3DS lo maneja Bancard.
  • La confirmación llega por callback y te la reenviamos por webhook (payment.confirmed / payment.failed). La reversa (POST /v1/payments/{id}/reverse) funciona el mismo día, antes de la liquidación.

→ Es el flujo cuando usás provider=bancard en POST /v1/payments. Solo PYG. Las tarjetas guardadas con Bancard (catastro + cobro con token) llegan en una fase posterior.

¿Puedo ofrecer varios en el mismo checkout?

Sí, y hay dos formas.

La más simple: checkout hospedado. Creás una CheckoutSession con los métodos que quieras y redirigís al comprador a una página nuestra, con tu logo y tus colores, donde él elige cómo pagar. No construís UI de pago ni embebés ningún iframe.

Armando la UI vos: la API es la misma para todos — solo cambia el campo provider (y, para tokenizado, agregás card_id si querés cobrar con una tarjeta ya catastrada). Tenés control total del diseño, a cambio de embeber el iframe y manejar los estados.