¿Moviendo fondos entre la propia cuenta bancaria y la propia billetera de un cliente? Usa Flujos de Primera Parte en su lugar.
Salida de definición
Al final del descubrimiento, tú y SpherePay deben acordar sobre:- Entidad legal de la plataforma (si aplica)
- Cliente de registro
- Remitente y beneficiario
- Propietario de fondos en cada paso
- Si la plataforma está en el flujo de fondos
- Tipo de usuario final — empresa, consumidor, o ambos
- Patrón de implementación — pago a proveedor, B2B de plataforma, o integración para consumidores
- Propósito del pago y razón del pago
- Documentos de respaldo e información de relación con el beneficiario, si es requerido
- Visibilidad requerida de remitente/destinatario en el wire o estado de cuenta
- Divisa fiat y riel; stablecoin y red si aplica
- Volumen mensual esperado, tamaño de transacción promedio y máximo
- Propietario de RFI y soporte al cliente
- Camino de endpoint y producto aprobado para la creación de pagos y polling de estado
Elige tu patrón
Empresa paga proveedor
Paga a un proveedor, vendedor, contratista o exportador — pueden aplican propósito del pago y documentos.
Plataforma sirve clientes empresariales
Fintech o plataforma que habilita a clientes empresariales finales a mover fondos.
Banco o fintech sirve consumidores
Ramps integrados para usuarios finales individuales — primero define el alcance del KYC, fraude y piloto.
| Patrón | Señales del descubrimiento | Enfoque principal de definición |
|---|---|---|
| Empresa paga proveedor | Entidad legal diferente recibe fondos; pago de factura/proveedor | Configuración del beneficiario, propósito, documentos |
| Plataforma sirve clientes empresariales | Plataforma + empresas finales; mapeo de ID de cliente | Cliente de registro, alcance de incorporación |
| Banco o fintech sirve consumidores | Usuarios finales individuales; UX integrada | Clasificación de usuarios, modelo de cumplimiento |
Patrón: Empresa paga proveedor
Usar cuando: Una empresa incorporada paga a un proveedor, vendedor, contratista, exportador u otro beneficiario tercero. Señales del descubrimiento:- El destinatario no es la misma entidad legal que el remitente
- Pago vinculado a una factura, orden de compra, contrato o relación de servicio
- Pueden ser requeridos el propósito del pago, el memo o los documentos de respaldo
- Puede aplicar liquidación transfronteriza — consulta Financiamiento comercial transfronterizo
| Parte | Pregunta de definición |
|---|---|
| Cliente de registro | ¿Quién está incorporado con SpherePay — el pagador, la plataforma u otro? |
| Remitente | ¿Quién inicia y financia el pago? |
| Beneficiario | ¿Quién recibe los fondos — y cómo deben ser registrados o revisados? |
| Propietario de fondos | ¿De quién es el dinero que se mueve en cada paso? |
Incorporar a las partes requeridas
Registra al pagador vía POST /v2/customer y completa el KYB empresarial o el KYC individual según corresponda.
Registrar el instrumento de origen del pagador
Vincula la cuenta bancaria o billetera del pagador.
Confirmar la configuración del beneficiario
Dependiendo del flujo, es posible que el beneficiario deba ser incorporado como cliente de SpherePay o revisado/registrado de alguna otra manera antes de que se puedan enviar los fondos. Confirma con SpherePay antes de la implementación.
Recopilar propósito y documentos
Reúne el propósito del pago, la razón del pago, el contexto de la relación y los documentos de respaldo — consulta Requisitos adicionales.
Crear el pago
Usa el endpoint soportado para tu flujo de tercera parte aprobado — confirma el camino con SpherePay antes de que comience la ingeniería.
Los pagos de tercera parte no son “transferencias de primera parte con un destinatario diferente.” El camino del endpoint, el modelo del beneficiario, los campos de cumplimiento y el manejo del estado pueden diferir. No asumas que POST /v2/transfer aplica.
Patrón: Plataforma sirve clientes empresariales
Usar cuando: Una fintech o plataforma habilita a sus clientes empresariales a mover fondos a través de SpherePay. Señales del descubrimiento:- Tu cliente es una plataforma, no solo un pagador final
- Las empresas finales envían o reciben fondos a través de tu producto
- Los IDs de clientes internos deben mapearse a los IDs de clientes de SpherePay
- La propiedad de RFI y soporte debe definirse antes del lanzamiento
Confirmar el alcance de incorporación
Decide si la entidad de la plataforma, cada empresa final, o ambas deben ser incorporadas — confirma con SpherePay.
Elegir un modelo de incorporación
Si usas la incorporación Platform-Managed, confirma la elegibilidad con el Área de Cumplimiento de Sphere antes de construir.
Crear y mapear registros de clientes
Usa POST /v2/customer para cada entidad que deba ser verificada. Mapea IDs internos a IDs de clientes de SpherePay.
Registrar instrumentos por parte
Registra cuentas bancarias y billeteras en los registros de clientes correctos.
Definir el camino de pago
Confirma el camino del endpoint para la creación de pagos y el polling de estado. Para resultados de aceptación fiat, consulta Aceptación de pagos.
Patrón: Banco o fintech sirve consumidores
Usar cuando: Una institución regulada o fintech expone ramps a usuarios finales individuales a escala. Señales del descubrimiento:- Los usuarios finales incluyen consumidores (no solo empresas)
- Se requiere on-ramp/off-ramp integrado o UX alojada
- La propiedad del KYC, los controles de fraude y las consideraciones de contracargo difieren del B2B
- Un piloto limitado en un corredor y segmento de usuarios es apropiado antes del despliegue amplio
Clasificar a los usuarios finales
Separa a los usuarios empresariales de los consumidores — los caminos de incorporación y los requisitos de socios difieren.
Confirmar la responsabilidad de incorporación
Define si SpherePay, tu plataforma, o un modelo híbrido maneja KYC/KYB, RFIs y soporte.
Definir la transferencia de datos
Documenta qué campos recopilas de forma previa vs. qué recopila SpherePay vía API o enlace alojado.
Elegir tu UX
Integración API vs Ramp Widget — basado en quién posee la experiencia de frontend.
Requisitos adicionales para pagos de tercera parte
Planifica recopilar y pasar lo siguiente cuando tu corredor aprobado lo requiera:- Propósito del pago — clasificación para cumplimiento y socios bancarios
- Razón del pago — descripción en lenguaje natural de por qué se mueven los fondos
- Código de propósito del pago — los valores permitidos varían por corredor; confirma el conjunto con SpherePay antes de construir
- Documentos de respaldo — contratos, facturas o evidencia de relación cuando se requiera
- Información de relación con el beneficiario — proveedor, contratista, vendedor de marketplace, etc.
- Visibilidad de remitente/destinatario — lo que el beneficiario ve en el wire o estado de cuenta
- Revisión antes de la liquidación — algunos flujos requieren revisión de documentos o manual; planifica la UX de estado en consecuencia
Confirmar antes de construir
Identificar a las partes
Confirma el cliente de registro, el remitente, el beneficiario y el propietario de los fondos en cada paso.
Definir el alcance del rol de la plataforma
Determina si la plataforma está en el flujo de fondos y si los usuarios finales son empresas, consumidores, o ambos.
Validar corredor y geografía
Confirma la disponibilidad de riel, divisa y región — incluyendo las restricciones de TX/PA para pagos de tercera parte.
Confirmar entradas de cumplimiento
Define el propósito del pago, los documentos requeridos, el modelo de configuración del beneficiario y la visibilidad de remitente/destinatario.
Confirmar el camino del endpoint
Verifica el camino aprobado para la creación de pagos y el polling de estado con SpherePay — consulta Creación de pagos y estado.
Creación de pagos y estado
Los caminos de pago de tercera parte son específicos del producto. La Referencia API pública documentaPOST /v2/transfer para flujos de on-ramp/off-ramp y transferencia cotizada. La creación de pagos B2B de tercera parte puede usar un camino de endpoint diferente — confirma con SpherePay antes de la implementación.
| Tipo de flujo | Orientación |
|---|---|
| On-ramp/off-ramp de primera parte | POST /v2/transfer — consulta Flujos de Primera Parte |
| Corredor fiat-a-fiat cotizado (cuando está habilitado) | POST /v2/quote luego creación de transferencia con quoteId — confirma aplicabilidad |
| Pagos B2B de tercera parte aprobados | Usa el camino del endpoint confirmado por SpherePay — no asumas la transferencia v2 de primera parte |
Qué enviar a Sphere antes del inicio
- Entidad legal de la plataforma (si aplica)
- Cliente de registro
- Remitente y beneficiario
- Propiedad de fondos en cada paso
- Si la plataforma está en el flujo de fondos
- Tipo de usuario final: empresa, consumidor, o ambos
- Patrón seleccionado: pago a proveedor, B2B de plataforma, o integración para consumidores
- Código de propósito del pago y razón del pago
- Tipo de documentación de respaldo, si es requerida
- Relación del beneficiario / contexto del destinatario
- Visibilidad requerida de remitente/destinatario
- Divisa fiat y riel; stablecoin y red si aplica
- Volumen mensual esperado
- Tamaño de transacción promedio y máximo
- Propietario de RFI/soporte
- Guía de Soluciones relacionada, si se identificó
Validar antes de que comience la ingeniería
| Bloqueo | Por qué importa |
|---|---|
| Perfil de verificación no aprobado | El perfil KYC/KYB requerido está incompleto, pendiente, faltante o rechazado |
| Proveedor/corredor no habilitado | Cliente aprobado en general pero no habilitado para el corredor o riel específico |
| Restricción de geografía/corredor | Los pagos de tercera parte no están disponibles en Texas ni Pennsylvania; otras regiones pueden tener límites |
| Cliente de registro poco claro | SpherePay no puede determinar quién debe ser incorporado |
| Plataforma en el flujo de fondos | Puede cambiar los requisitos de incorporación, cumplimiento y socios |
| Beneficiario no identificado | El pago no puede evaluarse ni enrutarse |
| Propósito de pago faltante o no soportado | Código de propósito requerido o razón faltante o no habilitada para el corredor |
| Documentos de respaldo faltantes | La liquidación puede bloquearse hasta que se proporcionen los documentos |
| Flujo de tercera parte usando supuestos de primera parte | Los patrones de tesorería/on-ramp pueden no aplicar a pagos de proveedores o plataformas |
| Endpoint incorrecto asumido | El camino de creación de pagos debe coincidir con tu producto de tercera parte aprobado |
| Escala de consumidores con patrón B2B | La integración para consumidores puede requerir un camino diferente |
Lista de verificación pre-inicio
- Cliente de registro, remitente y beneficiario identificados
- Propiedad de fondos y rol de plataforma documentados
- Patrón seleccionado y confirmado con SpherePay
- Partes requeridas incorporadas o configuración del beneficiario confirmada para el corredor
- Proveedor/corredor y geografía validados (incluyendo TX/PA)
- Propósito del pago, razón y documentos recopilados si es requerido
- Camino del endpoint para creación y estado confirmado con SpherePay
- Propietario de RFI/soporte definido
- Plan de conciliación definido
- Entradas de inicio enviadas a SpherePay
Antes del lanzamiento
SpherePay no tiene un sandbox separado — las pruebas de integración se ejecutan contra producción con datos de identidad reales. Ejecuta una transferencia en vivo de bajo monto en cada corredor antes del lanzamiento. La primera transferencia a un nuevo beneficiario puede activar un RFI de cumplimiento del socio bancario. Establece esta expectativa con tu cliente desde el inicio, y asegúrate de que tu propietario de RFI y soporte al cliente esté listo para responder. Para preguntas de liquidación de usuarios finales, comparte los artículos de la Base de Conocimiento de SpherePay When will the funds land in my account? y My funds are missing or have not landed in my account para que los usuarios se autoatiendan en lugar de abrir tickets de soporte contigo.Profundizar
Nómina
Desembolsos de tercera parte a empleados y contratistas.
Financiamiento comercial transfronterizo
Patrones de liquidación de importador–exportador y facturas.
Aceptación de pagos
Aceptación fiat mediada por plataforma con liquidación en stablecoin.
Flujos de Primera Parte
Cuando origen y destino pertenecen a la misma entidad legal.
Base de Conocimiento y FAQ
Artículos de soporte para usuarios finales — tiempos de liquidación, fondos faltantes, mínimos y guías del panel — para compartir con tus usuarios.