01Todos los métodos en una página
El checkout alojado reúne tarjetas, Apple Pay, Google Pay y USDC lado a lado. El pedido 9F21-0716 va a la izquierda — tres líneas, una comisión de procesamiento de €0.50, €49.00 a pagar — y la elección del método a la derecha. El cliente elige; la página se adapta; el comercio integró una sola vez.
- Botones de tarjeta, USDC y wallets en la misma pantalla
- El pedido completo — artículos, comisiones, total — junto al formulario de pago
- Una sola acción Pay €49.00 sea cual sea el método
02Móvil desde la misma URL
La misma URL de checkout se reorganiza en un diseño para móvil: el pedido se pliega en una barra de resumen, los botones de método se quedan donde están y el formulario de tarjeta conserva sus etiquetas. Lo que se publica en escritorio se publica en móvil — y cuando quieres que el pago ocurra dentro de tu propia app y no en un navegador, los SDK de iOS y Android presentan el mismo checkout de forma nativa sobre el mismo pedido.
03Recibos que se explican solos
Pagar con USDC termina en un recibo que el contable del comercio puede leer. Método: 52.95 USDC en Base →︎ liquidación en EUR, al tipo impreso en el recibo, 1 EUR = 1.0807 USDC. Referencia 9F21-0716, enviado por email al cliente y descargable al instante. El cliente pagó en cripto; la contabilidad dice €49.00.
04Un back office de enlaces, no solo enlaces
Los enlaces de pago tienen un puesto de trabajo de verdad: 8 enlaces de Arc Studio SRL entre pagados, activos y caducados, con importe, número de pagos y estado en cada fila. Las tarjetas superiores llevan la cuenta — 4 enlaces activos, €2,304.50 cobrados este mes en 18 pagos por enlace, €49.00 pagados hoy. Crear, buscar, exportar, listo.
- Cada enlace con su URL, importe y estado
- Cobrado este mes y pagado hoy, arriba del todo
- Crea un enlace en la misma vista donde les haces seguimiento
05Reembolsos sobre el pedido
Un reembolso apunta al pedido, no a un método de pago. El panel se abre sobre 9F21-0716 con el importe preestablecido en los €49.00 completos, un motivo obligatorio y una nota opcional que llega a las exportaciones y al recibo del cliente. Los fondos vuelven automáticamente por el mismo carril del pago original — los reembolsos de tarjeta a la tarjeta, los pedidos en USDC como su liquidación en EUR — normalmente en 1–3 días laborables.
- Totales o parciales — cualquier importe hasta el cargo original
- Motivo obligatorio, nota trasladada al recibo
- La ruta original se deshace automáticamente, en cualquier carril
06Tu checkout, con tu sello
La marca es una página de ajustes, no un proyecto de servicios: sube un logo, define los colores de acento, tinta y superficie, elige la tipografía y el estilo de las esquinas. La vista previa en vivo muestra tu checkout real — escritorio o móvil — antes de guardar, y el acento marca el foco del botón de pago, los checks de estado y la pestaña activa. Úsalo en el host de checkout asignado con tu sandbox o en tu propio dominio.
07Métodos que activas, no que construyes
Los métodos de pago son interruptores con proveedores detrás: tarjetas con 3-D Secure, Apple Pay y Google Pay como botones de wallet, USDC en Ethereum, Base y Solana, transferencia bancaria SEPA con referencia vIBAN. A su lado, el panel de liquidación lo dice claro: los clientes ven la conversión antes de confirmar; tú siempre liquidas en EUR.
- Interruptor por método, con el proveedor indicado en la fila
- Liquidación de USDC: conversión automática, pago diario a las 23:00
- Enrutamiento de tarjetas con la política de 3-D Secure a la vista
08Integración drop-in
Crea un pedido, redirige a la página alojada, recibe el resultado. Gateway se encarga de la interfaz de pago, la lógica de los métodos y los recibos. No hay un frontend de checkout que tu equipo tenga que construir, parchear o mantener al día cuando cambian los métodos.
09El pedido es la unidad
Todo cuelga del pedido, no del método de pago. El pedido 9F21-0716 lleva sus líneas — un sprint de identidad de marca de €38.50, licencia tipográfica de €6.00, entrega urgente de €4.00 —, una comisión de procesamiento de €0.50 y un único total. Se pague como se pague, esa referencia es la que consultas, concilias y reembolsas.
10Configuración que no sorprende a una sesión
Los cambios de métodos y de marca se aplican a las nuevas sesiones de checkout — lo indica la pantalla donde los guardas. Un cliente en pleno pago nunca ve cambiar la página bajo sus manos.
11Tarjetas, bien hechas
El flujo de tarjeta es la parte aburrida, resuelta: validación en línea, 3-D Secure con autenticación reforzada del cliente integrada en el flujo bajo una política de enrutamiento legible, y tarjetas de prueba por sandbox para las integraciones. Aceptar cripto nunca empeora el flujo de tarjeta.
12Apple Pay y Google Pay
Las wallets son botones, no proyectos. Apple Pay y Google Pay aparecen como hojas de un toque en la misma página y pagan con tokens del dispositivo — el número real de la tarjeta nunca llega a la página — a través del mismo pedido y el mismo recibo. Activarlas es un interruptor en la pantalla de métodos.
13USDC liquidado en EUR
El cripto se cotiza a un tipo mostrado en el checkout y se liquida en euros. El comercio nunca acaba con una posición en tokens por accidente; la contabilidad se mantiene en una sola moneda.
14USDC en tres redes
El método USDC abarca Ethereum, Base y Solana tras un único interruptor. El cliente paga en la red donde vive su wallet; por parte del comercio no cambia nada.
15Transferencia bancaria con vIBAN
El pago por transferencia lleva una referencia vIBAN, de modo que un pago SEPA entrante identifica su pedido por construcción. Actívalo para los clientes que prefieren una factura que pagar desde el banco, y la conciliación sigue siendo automática.
16Métodos locales donde importan
Además de tarjetas y wallets, el checkout ofrece los métodos de cuenta a cuenta y locales que un comprador europeo espera encontrar, presentados según el país del cliente y no volcados en una lista interminable.
17Compra ahora, paga después
BNPL está en la misma fila de métodos que todo lo demás — el cliente fracciona el pago, el comercio cobra una sola vez y la referencia del pedido no cambia. Un interruptor, el mismo recibo, la misma conciliación.
18Métodos que leen al cliente
La página ordena los métodos según lo que el cliente probablemente usará — país, idioma, dispositivo y si ya te ha pagado antes — para que la opción relevante sea la primera y no la cuarta.
19Precio en su moneda, liquidación en la tuya
Muestra el importe en la moneda del cliente con la conversión indicada antes de confirmar, y liquida en EUR en cualquier caso. El cliente ve una cifra familiar; tu libro mayor conserva una sola.
20Un checkout en su idioma
La página alojada localiza sus etiquetas, errores y recibos. Nadie abandona un pago porque el botón estaba en otro idioma.
21Tarjetas guardadas y pago en un clic
Un cliente recurrente paga con una tarjeta guardada con un toque. La tarjeta se custodia en nuestro lado y se referencia mediante un token, así que tus sistemas guardan una referencia, nunca un PAN — y la segunda compra es más corta que la primera.
22Suscripciones y facturación recurrente
Los cobros recurrentes siguen un calendario que defines — importe, intervalo, inicio y fin — sobre una tarjeta tokenizada. Cada ciclo genera su propio pedido y su propio recibo, de modo que una suscripción se concilia línea a línea como todo lo demás.
23Reintentos que recuperan ingresos
Un rechazo blando en un cobro recurrente se reintenta según un calendario en lugar de darse por perdido, y al cliente solo se le avisa cuando importa. Las renovaciones fallidas dejan de ser churn silencioso.
24Network tokens y actualización de tarjetas
Las tarjetas guardadas se almacenan como network tokens y acompañan al titular en reemisiones y caducidades. La suscripción que antes se rompía al sustituir una tarjeta sigue cobrando.
25Una API y un espacio para desarrolladores
Los pedidos se crean por API con claves de idempotencia — una petición reintentada devuelve el resultado original, nunca un segundo cobro — y la sección de desarrolladores incluye las claves y la documentación. El checkout está alojado; la integración son unos pocos endpoints, documentados donde están los ajustes.
26Webhooks sobre el ciclo de vida del pedido
Tu backend se entera de los pagos en el momento en que ocurren: eventos webhook firmados sobre el ciclo de vida del pedido — pagado, fallido, reembolsado — con verificación de firma por tu parte y protección frente a repeticiones por la nuestra.
27SDK móviles para iOS y Android
Las apps nativas presentan el mismo checkout dentro de la app en lugar de enviar al usuario a un navegador. El SDK incluye la lógica de métodos, las hojas de wallet y 3-D Secure; el pedido y el recibo son los que tu backend ya conoce.
Los plugins de carrito de compra conectan una tienda existente con Gateway sin un desarrollador — instala, pega las claves, haz un pago de prueba. Los pedidos llegan al mismo back office que los de la API.
29Campos embebidos en tu propia página
Cuando el pago tiene que ocurrir dentro de tu propio diseño, embebe directamente los campos de pago: los inputs están alojados y bajo alcance PCI en nuestro lado, la página que los rodea es totalmente tuya y los datos de la tarjeta nunca tocan tus servidores.
30Pago único, múltiple y caducidad
Un enlace puede cerrarse tras un pago o seguir cobrando: la plaza del taller de la demo lleva 3 pagos; la hora de consulta, 6. Por defecto, los enlaces caducan a los 30 días y, al caducar, lo indican en lugar de fallar en silencio.
31Modo de prueba
Las integraciones se ejecutan contra sesiones de prueba, con las tarjetas emitidas junto a tus claves de sandbox, antes de que se mueva nada real. Los flujos son idénticos: lo que pasa en pruebas es lo que sale a producción.
32Enrutamiento legible
El tráfico de tarjetas sigue una política de enrutamiento escrita en términos que reconoces —marca de la tarjeta, país emisor, divisa, importe— y no una caja negra. Ves qué ruta siguió un pago desde la misma pantalla que muestra el pago.
33Un segundo intento antes de perder la venta
Un rechazo blando se reintenta por una ruta alternativa dentro de la misma sesión de checkout, antes de que el cliente vea un fallo. La mayoría de los pagos recuperados son pagos que el cliente nunca supo que estaban en riesgo.
34Rechazos en lenguaje claro
Los códigos en bruto del emisor se traducen en motivos sobre los que un operador puede actuar —tarjeta caducada, fondos insuficientes, riesgo del emisor— y se agrupan para que un patrón repetido en muchos pagos se vea como patrón.
353-D Secure como política, no como fricción
La mayoría de los pagos pasan solo con señales del dispositivo y del comportamiento; el desafío de autenticación reforzada aparece cuando la política lo exige. Tú defines la política —siempre, según riesgo, o exención donde las normas lo permitan— y la página alojada gestiona el flujo.
36Una sola línea para conciliar
Checkout, recibo y liquidación comparten la misma referencia de pedido. Quien busque 9F21-0716 encuentra un único apunte de €49.00, no un registro de tarjeta en un sistema y uno cripto en otro.
37Liquidación y abonos
La liquidación se define donde la configuras: conversión automática a EUR, liquidación en RO49 •••• 0421, abono diario a las 23:00. La cifra que verá mañana el contable se decide hoy en una pantalla que el comercio puede leer.
38Un abono con trazabilidad
Cada abono se abre en los pedidos que lo generaron, con las comisiones desglosadas. La línea del banco coincide con una lista exportable, así que el cierre de mes es una consulta, no una investigación.
39Reembolsos parciales
El importe del reembolso es editable hasta el cargo original: el panel muestra el máximo y trata cualquier cantidad inferior como parcial. Diez reembolsos parciales sobre un pedido se concilian con una sola referencia.
40Motivos de reembolso registrados
Cada reembolso lleva un motivo obligatorio y una nota opcional, y la nota viaja: aparece en las exportaciones y en el recibo del cliente. Seis meses después, nadie tiene que recordar por qué se compensó el pedido 9F21-0716.
41Envío de recibos
Los recibos se envían por correo al cliente y se pueden descargar al instante; los recibos de reembolso siguen el mismo camino. El comercio nunca tiene que crear una plantilla de recibo.
42Anulación antes de la liquidación
Cancelar antes del lote del día libera la retención de la autorización y no se mueve dinero: ni reembolso, ni comisión, ni nada en el extracto del cliente que haya que explicar.
43Controles de riesgo activados por defecto
Los pagos con tarjeta ejecutan 3-D Secure bajo una política de enrutamiento legible. Los pagos con wallet llevan la autenticación del propio dispositivo, y los eventos de webhook se verifican por firma antes de darlos por buenos.
44Reglas escritas a tu manera
Las reglas de screening se leen como frases —importe superior a X desde el país Y con una tarjeta nueva— y actúan en consecuencia: permitir, desafiar o bloquear. Tras la misma pantalla hay listas de tarjetas, correos y direcciones de confianza o bloqueados.
45Señales de frecuencia y de dispositivo
Los intentos repetidos desde una tarjeta, un dispositivo o una dirección los detectan reglas de frecuencia, no una persona que se da cuenta más tarde. Las señales se muestran en el pago, no enterradas en una puntuación.
46Disputas con las pruebas adjuntas
Un contracargo se abre con el pedido que lo origina: resultado de la autorización, resultado de 3-D Secure, recibo, entrega, historial de reembolsos. Responde desde esa pantalla y el paquete de pruebas se arma a partir del registro, no de la memoria.
47Los datos de tarjeta nunca llegan a ti
La página que recoge los datos de la tarjeta es nuestra: alojada y dentro del ámbito PCI. Tanto si el cliente paga en nuestro dominio, en el tuyo o dentro de tu app, tus servidores ven un token y una referencia de pedido, nunca un número de tarjeta.
48Cifrado en reposo, en la UE
Los datos de pago se cifran en reposo y se procesan en la UE. Para un comercio europeo, dónde viven los datos es una respuesta, no una nota al pie.
49Cada acción, registrada
Reembolsos, cambios de método, cambios de marca, rotaciones de claves: todo queda en un registro de auditoría con el operador, la marca de tiempo y el motivo. Las acciones con privilegios exigen un motivo antes de ejecutarse.
50Roles para quien los necesita
Finanzas ve los abonos, soporte ve los pedidos y emite reembolsos, desarrollo ve claves y logs. El acceso se concede por rol, sin compartir un único usuario.
51Un directorio de clientes
Los pagadores se acumulan en una vista de clientes —quién pagó, cuántas veces, con qué método— para que un cliente recurrente sea un registro y no una coincidencia de correos en las exportaciones.
52Búsqueda y exportación a CSV
Encuentra un pago por enlace o referencia desde el buscador; exporta la vista actual a CSV cuando contabilidad lo pida. El back office da por hecho que alguien de contabilidad preguntará.
53Las cifras, por día y por método
Volumen, tasa de aprobación, reembolsos y mix de métodos, en el periodo que elijas. Lo justo para saber adónde fue el dinero y qué método merece la pena promover, sin exportar nada.
54La vista de operador que lo respalda
Gateway se conecta a Protocore Center: el back office de enlaces de pago muestra cada enlace con su transferencia de liquidación adjunta y un enlace para abrirlo en Tracer con la traza completa. Tu equipo de operaciones ve desde el checkout hasta el libro mayor.
55Whitelabel o powered-by
El checkout de la demo pertenece a Arc Studio SRL: su nombre, su marca, su pedido. Úsalo con un pie «powered by Protocore» o totalmente whitelabel: en ambos casos, la página se lee como tuya.
