Interac Canadá: e-Transfer y límites

1) Contexto y lugar de Interac en el ecosistema de pago

Interac e-Transfer es un popular riel de P2P/P2B/P2M dentro de Canadá que opera a través de bancos y cooperativas de crédito. La paga sale al email/número de teléfono del destinatario o directamente a su cuenta bancaria a través de Autodeposit. Las transferencias son casi instantáneas y están disponibles 24/7, mientras que la acreditación final y los límites dependen de una entidad financiera específica (FI).

• Direccionamiento sin detalles: envío por correo electrónico/teléfono; el destinatario selecciona el banco a acreditar.
• Autodepositivo: abono automático a la cuenta del destinatario sin una pregunta secreta.
• Dinero requerido: «solicitud de pago» con el importe y la asignación, confirmada por el pagador.
• Disponibilidad nativa: apoyada por la mayoría de los bancos canadienses en banca móvil/online.
• Las comisiones y los límites están determinados por los bancos/planes de cuentas, no por un único «esquema».

2) Participantes y roles

Interac es un operador de red, enrutamiento y reglas de servicio.
Pagador FI (Sender FI): inicia la traducción, aplica KYC/AML, límites y antifraude.
FI del destinatario (Recipient FI): acredita fondos, mantiene Autodeposite/Request Money.
El pagador es un individuo/negocio que paga por correo electrónico/teléfono/solicitud.
Merchant - destinatario del negocio; puede utilizar Autodeposits y/o las funciones corporativas de e-Transfer for Business en su banco.

3) Identificadores y direcciones

Email/El número de teléfono es el principal «alias» del destinatario.
Dirección autodepositiva: el número de correo electrónico está vinculado a la cuenta bancaria específica del destinatario; la traducción cae inmediatamente sin Q & A.
Destinatario por contacto: la libreta de direcciones del banco mantiene a los beneficiarios verificados (afecta las políticas de riesgo y los límites en algunas FI).
Referencia de pago: texto de destino/número de pedido; se enrolla en el recibo y los informes.

4) Flujos de pago

4. 1 P2P/P2B (push)

1. El remitente especifica el correo electrónico/teléfono del destinatario y el importe.
2. (Opcional) Pregunta secreta/respuesta de Q&A - Si el destinatario no tiene Autodeposit. configurado.
3. El destinatario recibe una notificación (email/SMS) → elige su banco/entra en el banco en línea → responde a una pregunta (si hay) → los fondos se acreditan.
4. Con Autodeposit, los pasos 2-3 se saltan: el dinero llega automáticamente.

4. 2 Request Money (collect)

1. El merchant envía una solicitud de suma/asignación al pagador.
2. El pagador confirma en el banco en línea → los fondos se envían como e-Transfer normal.
3. Merchant recibe una notificación y una inscripción.

4. 3 Para empresas (e-Transfer for Business)

Soporte de escenarios de bulk en varios bancos (solicitudes/pagos masivos).
Informes avanzados y límites de cuentas corporativas.
La API/host-to-host del banco está a menudo disponible para integrarse en ERP/facturación.

5) Límites y cómo trabajar con ellos

Los límites los establece el banco del pagador (y a veces el destinatario) y dependen del tipo de cuenta, historial, perfil KYC/AML y riesgo.

• Per-transaction - máximo por operación.
• Per-day/24h es la suma diaria.
• Semanal/Monthly - topes semanales/mensuales por suma/cantidad.
• Nuevo destinatario: límites temporalmente reducidos y/o extracto para las primeras transferencias a un nuevo contacto.
• Q&A vs Autodeposit- Con Autodepositus, una parte de los bancos tienen otros umbrales y controles.
• Dinero requerido: los límites pueden diferir del envío «normal».
• Business/Treasury: las cuentas corporativas a menudo tienen límites básicos triplicados y cuotas flexibles de acuerdo.

• No codifique los números: mantenga un directorio de límites de bancos/planes y actualícela.
• En UX, muestre el error informativo «excedido el límite de su banco» + sugerencia de opciones (aplastamiento, otro método).
• Para secuencias de comandos recurribles, utilice Dinero requerido con la memoria automática del destinatario y/o rieles alternativos (débito PAD/ACH).

6) Seguridad, Q&A y Autodeposits

Q&A (pregunta/respuesta secreta) protege la traducción si Autodepositus no está configurado en el destinatario. La respuesta se transmite en forma cifrada y se requiere para la inscripción.
Autodeposit reduce el riesgo de phishing por Q&A y acelera el flow - recomendado para los merchantes.
Notification hardening: avisa a los clientes que el banco nunca pide PIN/contraseñas por correo electrónico/SMS; enseñe a reconocer «solicitudes de pago» de phishing.
Control de dispositivo/IP/velocidad a nivel de banco del pagador.

7) Estados, cancelaciones y devoluciones

Pending/In Progress/Completed/Failed/Expired - estados típicos.
Antes de que el destinatario acepte, la transferencia puede ser revocada (cancel) por el remitente en su banco (si no Autodepositus).
Chargeback como no hay mapas. La devolución después de la inscripción es una nueva operación de crédito del merchant al pagador.
La referencia parcial se admite a través de operaciones individuales.
En casos polémicos (fraude, error del destinatario), la escalada pasa por los bancos y las regulaciones de apoyo.

8) Conciliación y presentación de informes

Guarde los identificadores bancarios de la transacción (número de confirmación/referencia), correo electrónico/teléfono del destinatario, importe, timestamp, destino.
Habilite daily auto-recon (operativo) y periódico full-recon (financiero).
Para pagos/solicitudes de bulk, utilice los informes bancarios/PSP con los resultados de cada línea (success/fail/expired/canceled).

9) Comisión y costes

El valor de e-Transfer está determinado por las tarifas del banco de la cuenta (a menudo una fix por envío; planes por lotes para empresas).
No hay comisión por recibir en merchantes/individuos más a menudo, pero las condiciones dependen de FI.
Hipotecar los costos de soporte (feed/phishing quejas), SLA de procesamiento de solicitudes y cancelar.

10) Riesgos y antifraude

Phishing por Q&A: un atacante intercambia correo electrónico/SMS e intenta atraer la respuesta. Es mitigado por Autodepositus, entrenando a los usuarios y limitando los intentos.
Dirección errónea: la confirmación del nombre del destinatario antes del envío es limitada: compensa con una retroiluminación UX del contacto y dos veces la confirmación de correo electrónico/teléfono.
Ingeniería social y «refund-scams»: almacene los scripts de verificación en sapport y los estándares de devolución.

11) iGaming y otras verticales sensibles

Los bancos y proveedores de pagos en Canadá aplican políticas categóricas: para determinados tipos de negocios, los límites y la disponibilidad de e-Transfer pueden ser limitados.
Espere límites reducidos, KYC avanzado y posibles requisitos de «fuente de fondos».
Mantenga raíles alternativos (por ejemplo, débito PAD/ACH, pagos con tarjeta, AFT) y segmentación de riesgo.

12) Integración de merchant

Opciones

1. Autodepositivo para la recepción

Inicio sencillo: publique un email/número, personalice Autodepositus.
Contras: entrada manual de la cantidad por el pagador (error), más débil por-orden por el analista.

2. Request Money (factura/collect)

Crea una solicitud con una cantidad fija/asignación → el pagador confirma.
Mejor en conciliación y conversión; es adecuado tanto para el pago único como para los pagos repetitivos.

3. Negocio e-Transfer a través del banco/PSP

Acceso a operaciones de bulk, límites extendidos, API/host-to-host.
Requiere una cuenta corporativa y un onboarding con FI.

• 'webhook/callback' sobre los estados (o encuesta sobre el backoff).
• Tabla de idempotencia (orderId + clave de consulta).
• Conector al informe recon bancario.
• Refund-flow (parcial/completo).
• Monitoreo de SLA (éxito/fallas/latencia/experiencias).

13) Recomendaciones UX

Para pagos one-off: apueste por Dinero requerido (menos errores, conciliación clara).
Muestre el temporizador de la actividad de solicitud, los estados claros y los pasos de repetición.
Seleccionemos: "Pagar ahora" (Request) o'Enviar manualmente "(Autodeposit/email/teléfono).
Pantalla de seguridad separada: acerca de Q&A, phishing, «nunca pedimos contraseñas».

14) Arquitectura «Interac Gateway»

API поверхности: `createRequest`, `cancelRequest`, `queryStatus`, `processRefund`, `reconcile`.
Fiabilidad: idempotencia, retraídas por exponente, dedoup por referencias externas del banco.
Datos: directorio de límites bancarios, tarjeta de destinatarios (nuevo/de confianza), estados expirados.
Seguridad: firmas HMAC de ganchos web, allowlist IP Bank/PSP, registro de auditoría, cifrado PII (email/teléfono).
Observabilidad: métricas de conversión por canal (Autodeposits vs Request), tiempo antes de la inscripción, cuota de expires/cancel.

15) Check-list de la salida en el prod

1. Seleccione un banco/PSP y un plan corporativo con los límites/API deseados.
2. Configure Autodeposits y/o Request Money; pruebe las experiencias/cancelaciones.
3. Implementar status/web hooks, idempotencia y recon.
4. Habilite los procedimientos Refund-flow y ODR en el sapport.
5. Agregue pantallas de seguridad (Q&A, phishing), errores de límites claros.
6. Inicie el monitoreo de SLA y alertas a través de bancos/canales.
7. Realice pruebas end-to-end con varias FI grandes.

Tarjeta de límites (puntos de referencia de diseño)

Per-txn/24h/7d/30d: almacenar en la configuración y comprobar antes de iniciar.
Nuevos destinatarios: umbrales reducidos temporalmente y/o extracto.
Autodeposits vs Q&A: diferentes umbrales y reglas antifraude son posibles.
Cuentas corporativas: límites elevados en la solicitud + dop. due diligence.

Resumen

Para la conciliación en línea y precisa, utilice Request Money; para una mera recepción - Autodeposit.
No «coser» números específicos: mantenga las confecciones de límites FI y actualícelas.
Incorpore refund/ODR, informes detallados y recon diario.
Capacite a los clientes de seguridad y ofrezca Autodeposite para un mejor UX y un frod más pequeño.