Este documento se publica como un anexo a la documentación de la API de CCBill y analiza la funcionalidad de actualización dinámica avanzada. Este documento está escrito para desarrolladores, técnicos y otras personas con habilidades de codificación avanzadas.
Las actualizaciones dinámicas avanzadas permiten a los clientes actualizar las suscripciones anteriores de los consumidores a una nueva suscripción sin configurar previamente un precio en el sistema. Las actualizaciones dinámicas avanzadas se pueden realizar en la misma subcuenta o en una subcuenta diferente, y el cliente las configura en su totalidad. Debido a que las actualizaciones dinámicas avanzadas no requieren que el consumidor vuelva a ingresar la información de pago, el cliente es responsable de albergar los términos de la actualización que se ofrece.
Las actualizaciones dinámicas avanzadas no requieren que se configuren actualizaciones preconfiguradas en el sistema de CCBill. Sin embargo, los puntos de precio se pueden crear en el área de precios del administrador del Webmaster de CCBill, al que se producirá la actualización.
El sistema admite actualizaciones de tarjetas de crédito y ACH (Cámara de compensación automatizada).
Las actualizaciones dinámicas avanzadas pueden admitir Precios regionales, con un paso adicional. Se realizarán dos solicitudes; la solicitud de actualización inicial calcula el nuevo precio y la segunda solicitud realmente realiza la transacción. Este proceso se describe en detalle más adelante en este documento.
Controles de velocidad CCBill es una característica avanzada de la API de CCBill y le permite limitar las transacciones de los clientes por el número de transacciones y / o por el monto en efectivo de las transacciones dentro de un período de tiempo específico. Esto significa que puede establecer el número de transacciones para un cliente específico dentro de un período de tiempo determinado.
Las reglas se aplican a todos los tipos de pago, y a cada cliente se le asigna una identificación única en función de su información financiera y antecedentes de seguridad. Al configurar CCBill Velocity Controls, limita las posibilidades de fraude y, de manera individual, permite que los buenos clientes leales continúen comprando más allá de los límites establecidos.
Nota: Cada regla se puede configurar en una sola subcuenta o en todas las subcuentas.
Si está interesado en esta función avanzada, comuníquese con merchandisingupport@ccbill.com para configurar controles de velocidad de acuerdo con los requisitos de su negocio.
Las actualizaciones dinámicas avanzadas se crean pasando parámetros a una cadena de consulta. Las solicitudes deben enviarse al siguiente script CGI con valores de variable adjuntos:
https://bill.ccbill.com/jpost/billingApi.cgiLa actualización se realizará pendiente de la validación de CCBill. Dependiendo del resultado de la validación, se devolverán diferentes resultados. Los resultados se pueden devolver en formato de valores separados por comas (CSV) o en formato XML. A continuación, se muestran ejemplos de cadenas de solicitud y su resultado potencial.
La siguiente lista describe el valor de cada campo para las actualizaciones dinámicas avanzadas.
Nota: If oferta especial se establece en cero (0), se debe incluir el parámetro de prorrateo. De lo contrario, no se utiliza el parámetro de prorrateo.
Todos los parámetros explicados anteriormente son obligatorios además de los campos obligatorios enumerados en la documentación principal de la API de CCBill. La siguiente tabla indica qué campos son obligatorios u opcionales:
| clienteAccnum | nombre de usuario | Contraseña | clienteSubacc | usandoSubacc | retornoXML | DE ACTUAR! | |
|---|---|---|---|---|---|---|---|
| Cuenta principal | ✔ | ✔ | ✔ | ✔ | |||
| Cuenta principal con XML | ✔ | ✔ | ✔ | ✔ | ✔ | ||
| Sub-cuenta | ✔ | ✔ | ✔ | ✔ | ✔ | ||
| Subcuenta con XML | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ |
| ID de suscripción | actualizaciónTypeId | actualizarClientAccnum | actualizarClienteSubacc | |
|---|---|---|---|---|
| Cuenta principal | ✔ | ✔ | ✔ | ✔ |
| Cuenta principal con XML | ✔ | ✔ | ✔ | ✔ |
| Sub-cuenta | ✔ | ✔ | ✔ | ✔ |
| Subcuenta con XML | ✔ | ✔ | ✔ | ✔ |
| Cuenta principal con oferta especial | ✔ | ✔ | ✔ | ✔ |
| Cuenta principal con XML | ✔ | ✔ | ✔ | ✔ |
| y oferta especial | ✔ | ✔ | ✔ | ✔ |
| Subcuenta con oferta especial | ✔ | ✔ | ✔ | ✔ |
| Subcuenta con XML y oferta especial | ✔ | ✔ | ✔ | ✔ |
| oferta especial | prorratear | anularAfiliado | anular la participación | |
|---|---|---|---|---|
| Cuenta principal | ✔ | ✔ | ||
| Cuenta principal con XML | ✔ | ✔ | ||
| Sub-cuenta | ✔ | ✔ | ||
| Subcuenta con XML | ✔ | ✔ | ||
| Cuenta principal con oferta especial | ✔ | |||
| Cuenta principal con XML | ✔ | |||
| y oferta especial | ✔ | |||
| Subcuenta con oferta especial | ✔ | |||
| Subcuenta con XML y oferta especial | ✔ |
Los siguientes ejemplos de código usan el UpgradeSubscription acción, que no admite precios regionales.
Solicitar cadena
https://bill.ccbill.com/jpost/billingApi.cgi?clientAccnum=900100&username=testUser&password=testPass&action=upgradeSubscription&subscriptionId=18902345789012343781¤cyCode=840&upgradeTypeId=14&upgradeClientAccnum=900100&upgradeClientSubacc=0000&specialOffer=1&sharedAuthentication=1Resultados enviados (para transacciones aprobadas):
Fields: "approved", "subscriptionId"
Values: "1", "100000000000000000"Resultados enviados (para transacciones denegadas):
Fields: "approved", "denialId", "declineCode", "declineText"
Values: "0", "100000000000745921", "15", "declined by bank"Resultados enviados (cuando ocurre un error)
Fields: "results"
Values: "-1"Solicitar cadena
https://bill.ccbill.com/jpost/billingApi.cgi?clientAccnum=900100&username=testUser&password=testPass&action=upgradeSubscription&subscriptionId=0108114301000018799¤cyCode=840&upgradeTypeId=14&upgradeClientAccnum=900100&upgradeClientSubacc=0000&specialOffer=1&sharedAuthentication=1&returnXML=1Resultados enviados (para transacciones aprobadas)
<?xml version='1.0' standalone='yes'?>
<results>
<approved>1</approved>
<subscriptionId>100000000000000000</subscriptionId>
</results>Resultados enviados (para transacciones denegadas):
<?xml version='1.0' standalone='yes'?>
<results>
<approved>0</approved>
<denialId>100000000000000000</denialId>
<declineCode>15</declineCode>
<declineText> declined by bank </declineText>
</results>Resultados enviados (cuando ocurre un error)
<?xml version='1.0' standalone='yes'?>
<results>-1</results>Para utilizar los precios regionales con actualizaciones dinámicas avanzadas, se deben realizar dos solicitudes. La primera solicitud es una solicitud de actualización dinámica avanzada estándar utilizando el obtener detalles de actualización acción. La primera solicitud solo devuelve datos; no se procesa ninguna transacción hasta que se envía la segunda solicitud. La primera solicitud devolverá datos que se utilizarán en la segunda solicitud como se describe a continuación.
La segunda solicitud se enviará mediante el CargoBypreviousTransactionId acción. Esta solicitud procesa la transacción de actualización.
Nota: Este documento solo describe el CargoBypreviousTransactionId acción con suficiente detalle para su uso con actualizaciones dinámicas avanzadas. Para obtener más información sobre esta acción, consulte el chargeByPreviousTransactionId apéndice a la Guía de la API de CCBill.
La primera solicitud devuelve los siguientes valores:
Una vez que los datos se hayan devuelto, envíe el URL de transacción de proceso valor como la segunda solicitud. Esto procesará la transacción.
Los siguientes ejemplos de código usan el obtener detalles de actualización acción para respaldar los precios regionales. Debido a que esta acción requiere una segunda solicitud para procesar realmente la transacción, se proporcionan ejemplos de código para ambas solicitudes.
Tenga en cuenta que la primera solicitud devuelve un valor llamado URL de transacción de proceso que contiene la cadena exacta necesaria para la segunda solicitud. Esta URL procesará la transacción real. La segunda solicitud devuelve datos que describen los resultados de la transacción.
Primera cadena de solicitud
https://bill.ccbill.com/jpost/billingApi.cgi?clientAccnum=999999&clientSubacc=0000&username=qatest1&password=testing1&action=getUpgradeDetails&prorate=2&subscriptionId=0908267201000000008&upgradeClientAccnum=999999&upgradeClientSubacc=0000¤cyCode=840&specialOffer=1&sharedAuthentication=0&upgradeTypeId=0000060948Datos devueltos de la primera solicitud
Fields: "currencyCode","recurringPriceDescription","initialPriceDescription","initialPeriod",
"initialPrice","recurringPrice","recurringPeriod","processTransactionUrl","rebills"
Values: "840","","$19.95(USD) for 30 days","30","19.95","12.95","30", "[link below]","99"Segunda cadena de solicitud
https://bill.ccbill.com/jpost/billingApi.cgi?clientAccnum=999999&clientSubacc=0000&username=qatest1&password=testing1&action=chargeByPreviousTransactionId&subscriptionId=0908267201000000008&newClientAccnum=999999&newClientSubacc=0000&specialOffer=1&sharedAuthentication=0¤cyCode=840&initialPrice=19.95&initialPeriod=30&recurringPrice=12.95&recurringPeriod=30&rebills=99Resultados enviados desde la segunda solicitud (para transacciones aprobadas)
Fields: "approved", "subscriptionId"
Values: "1", "1234567890"Resultados enviados desde la segunda solicitud (para transacciones denegadas):
Fields: "approved", "denialId", "declineCode", "declineText"
Values: "0", "100000000000000000", "15", "declined by bank"Resultados enviados desde la segunda solicitud (cuando ocurre un error)
Fields: "results"
Values: "-1"https://bill.ccbill.com/jpost/billingApi.cgi?clientAccnum=999999&clientSubacc=0000&username=qatest1&password=testing1&action=getUpgradeDetails&prorate=2&subscriptionId=0908267201000000008¤cyCode=840&upgradeClientAccnum=999999&upgradeClientSubacc=0000&specialOffer=1&sharedAuthentication=0&upgradeTypeId=0000060948Datos devueltos de la primera solicitud
<results>
<currencyCode>840</currencyCode>
<initialPeriod>30</initialPeriod>
<initialPrice>19.95</initialPrice>
<initialPriceDescription>$19.95(USD) for 30 days</initialPriceDescription>
<processTransactionUrl>[link below]</processTransactionUrl>
<rebills>99</rebills>
<recurringPeriod>30</recurringPeriod>
<recurringPrice>12.95</recurringPrice>
<recurringPriceDescription/>
</results>Segunda cadena de solicitud
https://bill.ccbill.com/jpost/billingApi.cgi?clientAccnum=999999&clientSubacc=0000&username=qatest1&password=testing1&action=chargeByPreviousTransactionId&subscriptionId=0908267201000000008&newClientAccnum=999999&newClientSubacc=0000&specialOffer=1&sharedAuthentication=0¤cyCode=840&initialPrice=19.95&initialPeriod=30&recurringPrice=12.95&recurringPeriod=30&rebills=99Resultados enviados desde la segunda solicitud (para transacciones aprobadas):
<?xml version='1.0' standalone='yes'?>
<results>
<approved>1</approved>
<subscriptionId>100000000000000000</subscriptionId>
</results>Resultados enviados desde la segunda solicitud (para transacciones denegadas):
<?xml version='1.0' standalone='yes'?>
<results>
<approved>0</approved>
<denialId>100000000000000000</denialId>
<declineCode>15</declineCode>
<declineText> declined by bank </declineText>
</results>Resultados enviados desde la segunda solicitud (cuando ocurre un error):
<?xml version='1.0' standalone='yes'?>
<results>-1</results>Independientemente de la acción que se utilice, se devolverán códigos numéricos si la solicitud falla debido a un error. Para obtener una lista completa de códigos de error y explicaciones, consulte el Guía de la API de CCBill.
API de 1 clic de CCBill Permitir a los comerciantes ofrecer a sus clientes una conveniente solución de facturación de actualización lo que permite a los clientes tener que volver a introducir sus datos de pago en compras posteriores. Las API son administradas por el comerciante y las transacciones las inician los consumidores dentro del sitio web del comerciante o del área de miembros. Si bien estas pueden ser herramientas muy convenientes y útiles, no vienen sin riesgo añadido. Se requiere que el comerciante administre gran parte de la experiencia del consumidor, y las API están diseñadas para evitar el sistema de autenticación de CCBill, V-Scrub.
Como resultado, es imperativo que el comerciante comprenda sus responsabilidades e implemente un sistema de controles diseñado para gestionar la experiencia del consumidor y minimizar el riesgo de devoluciones de cargo y pérdida de ingresos.
Si bien el modelo comercial de cada comerciante es inherentemente único y los controles que implementan pueden diferir, lo siguiente y las mejores prácticas actuar como una guía para los comerciantes que procesan Transacciones con 1 clic.