¿Cuáles son algunas de las características de una excelente API de pagos y banca?

He trabajado con muchos proveedores de pagos y actualmente estoy trabajando con uno que está desarrollando una nueva API. Busco lo siguiente:

  • Estructura de costos clara y registro automatizado. Algunos proveedores todavía pertenecen a un banco más antiguo, una industria que avanza lentamente. Quieren que comience una relación antes de que le dé acceso y le diga sus precios.
  • Documentos de API públicos. ¡No escondas nada!
  • Soporte de pago recurrente (si lo necesita). Se está volviendo común, pero aún no es universal.
  • Datos de la tarjeta de crédito almacenados por el proveedor. Bastante común, y requerido para pagos recurrentes, ¡pero no toque las puertas de enlace que no hacen esto! Te estás abriendo a todo tipo de responsabilidad.
  • Soporte para todas las tarjetas principales. Esto está prácticamente garantizado ahora, pero aún así verifique.
  • Modo sandbox / debug, para facilitar el desarrollo.
  • Tarjetas de desarrollo, que se pueden usar en modo en vivo sin cargo. Debería haber cartas que produzcan todo tipo de error posible.
  • Tarifas competitivas. Eso significa competitiva con PayPal y Amazon, y sin tarifas ocultas (como cargos por transacciones fallidas).
  • Pantallas de pago personalizables, que no tienen que mostrar un logotipo. O bien, totalmente utilizable a través de los servicios para que podamos hacer nuestras propias pantallas localmente. O ambos.
  • Soporte para devoluciones de llamada, con puntos finales personalizables.
  • Y, a veces, una base de datos de tarjetas de crédito existente: agregar Amazon o Google (o, en menor medida, PayPal) puede aumentar la conversión de pagos para las personas que tienen sus datos de tarjeta de crédito almacenados con ellos.

Granularidad suficiente para manejar cualquier situación. Diseñé esa estructura y la llamo una pila de transacciones:

La oferta inicial de mí es 100 IBM.
Mis términos son $ 10,000.
Su contraoferta es de $ 9,900.
Acepto. Esto es ahora un contrato.
Usted entrega $ 9,900.
Entrego 100 IBM.
Fin de la transacción.

Pagos, intercambios, bancos, cualquier cosa de valor. Seguimiento de auditoría total con marcas de tiempo en cada evento.

Entonces, la tabla tiene 5 columnas:
ID de transacción
CommerceID o ID de usuario
Tipo de evento
Descripción
Sello de tiempo

La columna de descripción debe contener tanto cantidad como valor. Se puede analizar. Si bien hay argumentos de que una sexta columna para la cantidad podría ser una buena idea, no creo que sea necesario y no todo el valor tiene una cantidad.

Lo anterior se puede poner en formato XML o JSON.

La API se escribe sola.

Txnid = Transaction.InitiateOffer (userid, value);
Transaction.Terms (Txnid, userid, description);
Transaction.CounterOffer (Txnid, otherUserid, valueDescription);
Etc.

Cuando se trata de API de banca, algunos artículos son un poco más vitales que otros.

  • Una variedad de modelos de integración (On Premise, SaaS, Client Side). No hay “Una solución para gobernarlos a todos”
  • Alta velocidad
  • Baja tasa de fracaso
  • Tecnología que permite una personalización completa
  • Precios claros y transparentes

Este es un recurso fantástico para saber qué características tiene una API bancaria excelente – API Guidebook