Conekta · Sandbox de integraciones

Tipos de integración de Conekta

Cómo se conecta un comercio con nosotros, qué cambia entre una forma y otra, y por qué eso explica después cosas como que una wallet no aparezca o que un canal apruebe distinto.

Todo sale de una sola pregunta: ¿quién muestra el formulario donde se teclea la tarjeta?

Si lo muestra el comercio, él carga con la seguridad y tiene control total. Si lo mostramos nosotros, cargamos nosotros y él casi no configura nada. De ahí cuelga el resto: qué métodos puede ofrecer, qué tan rápido le prendemos algo nuevo, y qué tanto se puede personalizar.

Los cuatro canales

Toca uno para ver cómo funciona.

Lado a lado

CanalFormularioPCIControl TransaccionesComerciosGPV pagado

Por qué esto importa en el día a día

Explica por qué un botón «no aparece»

En Conekta hay dos decisiones separadas:

Render
¿Aparece el botón? Lo deciden las flags de la compañía y, en checkout, una flag por canal.
Cobro
¿Procede el cargo? En checkout lo decide Resource Manager; en API directa, la configuración maestra.
Que estén separadas es la causa del bug clásico «botón sí, cobro no»: el botón renderiza y el cargo truena. Si un comercio reclama que una wallet no le sirve, la primera pregunta es por qué canal procesa — porque en API directa el botón depende de que él lo haya integrado, no de que nosotros prendamos algo.

Explica el techo de los plugins

Cada plugin cae casi siempre en un canal:

PluginCanal dominante
ShopifyRedirigido (87%)
WooCommerceAPI directa (79%)
VTEXAPI directa (100%)
MagentoEmbebido (100%)
PrestaShopAPI directa (95%)
Ojo con Shopify: hoy tiene un candado que impide renderizar Apple Pay en su checkout hosteado. Google Pay sí renderiza. No es un problema del comercio — es cómo está construido.

Cambia qué tan rápido podemos mover la aguja

En checkout (redirigido, embebido, link) basta con prender flags — lo controlamos nosotros. En API directa cada comercio tiene que meter código: es venta técnica, no configuración. Como el volumen está justo en API directa, cualquier iniciativa de wallets choca con esto.

Cómo saber por qué canal procesa un comercio

En el DW (warehouse.tb_charge, ds 11):

Si…Entonces el canal es
checkout_request_id IS NULLAPI directa
checkout_request_type_desc = 'PaymentLink'Payment Link
checkout_request_type_desc = 'HostedPayment'Redirigido
checkout_request_type_desc = 'Integration'Embebido

Un comercio puede usar varios canales a la vez — no es una etiqueta fija, es cómo entró cada cargo.

Glosario rápido

Canal de integraciónLa vía por la que el comercio procesa (los 4 de arriba)
TokenizarCambiar el número de tarjeta por un código que no sirve fuera de ese cobro. Así el comercio no guarda tarjetas
PCIEl estándar de seguridad para manejar datos de tarjeta. Quien muestra el formulario, carga con él
Render vs CobroQue aparezca el botón ≠ que proceda el cargo. Decisiones separadas
Resource Manager (RM)El servicio que autoriza si un cargo de checkout procede
Embebido / IntegrationEl mismo canal. «Integration» es como se llama en los datos
Redirigido / HostedEl mismo canal. «HostedPayment» en los datos