Procesando pagamientos con Bitcoin

[socrates980]

El procesamiento de pagos abarca los pasos que realizan los gastadores y los receptores para realizar y aceptar pagos a cambio de productos o servicios. Los pasos básicos no han cambiado desde los albores del comercio, pero la tecnología sí.
Introducción
Esta sección explicará cómo los receptores y los gastadores pueden, respectivamente, solicitar y realizar pagos usando Bitcoin, y cómo pueden lidiar con complicaciones como reembolsos y reembolsos recurrentes.






Procesamiento de pagos de Bitcoin
La figura anterior ilustra el procesamiento de pagos utilizando Bitcoin desde la perspectiva de un receptor, comenzando con un nuevo pedido. Cada una de las siguientes subsecciones abordará los tres pasos comunes y los tres pasos ocasionales u opcionales.
Cabe mencionar que cada uno de estos pasos se puede subcontratar mediante el uso de API y servicios de terceros.
Órdenes de precios
Debido a la variabilidad del tipo de cambio entre satoshis y monedas nacionales (fiat), muchos pedidos de Bitcoin tienen un precio en fiat pero se pagan en satoshis, lo que requiere una conversión de precio.
Los datos de tipos de cambio están ampliamente disponibles a través de API basadas en HTTP proporcionadas por los intercambios de divisas. Varias organizaciones también agregan datos de múltiples intercambios para crear precios de índice, que también están disponibles mediante API basadas en HTTP.
Cualquier aplicación que calcule automáticamente los totales de los pedidos utilizando datos de tipos de cambio debe tomar medidas para garantizar que el precio cotizado refleje el valor de mercado general actual de los satoshis, o las aplicaciones podrían aceptar muy pocos satoshis para el producto o servicio que se vende. Alternativamente, podrían pedir demasiados satoshis, alejando a los posibles consumidores.
Para minimizar los problemas, es posible que sus aplicaciones deseen recopilar datos de al menos dos fuentes independientes y compararlas para ver en qué se diferencian. Si la diferencia es sustancial, sus aplicaciones pueden entrar en modo seguro hasta que un humano pueda evaluar la situación.
Es posible que también desee programar sus aplicaciones para que entren en modo seguro si los tipos de cambio cambio o disminuyen rápidamente, lo que indica un posible problema en el mercado de Bitcoin que podría dificultar el gasto de los satoshis recibidos hoy.
Los tipos de cambio están fuera del control de Bitcoin y las tecnologías relacionadas, por lo que no hay tecnologías nuevas o planificadas que faciliten significativamente la conversión de los totales de los pedidos de fiat a satoshis de manera significativa para su programa.
Debido a que el tipo de cambio fluctúa con el tiempo, los totales de los pedidos vinculados a fiat deben expirar para evitar que los gastadores retrasen el pago con la esperanza de que los satoshis bajen de precio. Los sistemas de procesamiento de pagos más utilizados actualmente caducan sus facturas después de 10 a 20 minutos.
Los períodos de vencimiento más cortos sufrió la posibilidad de que la factura venza antes de que se reciba el pago, lo que posiblemente requiera una intervención manual para solicitar un pago adicional o emitir un reembolso. Los períodos de vencimiento más largos sufrieron la posibilidad de que el tipo de cambio fluctúe una cantidad significativa antes de que se reciba el pago.
Solicitación de pagos
Antes de solicitar el pago, su aplicación debe crear una dirección de Bitcoin o adquirir una dirección de otro programa como Bitcoin Core. Las direcciones de Bitcoin se describen en detalle en la guía Transacciones. En esa sección también se describen dos razones importantes para evitar usar una dirección más de una vez, pero una tercera razón se aplica especialmente a las solicitudes de pago:
El uso de una dirección separada para cada pago entrante hace que sea trivial determinar qué clientes han pagado sus solicitudes de pago. Sus aplicaciones solo necesitan rastrear la asociación entre una solicitud de pago en particular y la dirección utilizada en ella, y luego escanear la cadena de bloques en busca de transacciones que coincidan con esa dirección.
Las siguientes subsecciones describirán en detalle las siguientes cuatro formas compatibles de dar al gastador la dirección y el monto a pagar. Para una mayor comodidad y compatibilidad, se recomienda proporcionar todas estas opciones en sus solicitudes de pago.
1. Todo el software de billetera permite a sus usuarios pegar o ingresar manualmente una dirección y un monto en una pantalla de pago. Esto es, por supuesto, un inconveniente, pero constituye una opción alternativa eficaz.
2. Casi todas las carteras de escritorio se pueden asociar con URI de “bitcoin:”, por lo que los usuarios pueden hacer clic en un enlace para completar previamente la pantalla de pago. Esto también funciona con muchas carteras móviles, pero generalmente no funciona con carteras basadas en la web a menos que el gastador instale una extensión del navegador o configure manualmente un controlador URI.
3. La mayoría de las carteras móviles admiten el escaneo de URI de “bitcoin:” codificadas en un código QR, y casi todas las carteras pueden mostrarlas para aceptar pagos. Si bien también es útil para pedidos en línea, los códigos QR son especialmente útiles para compras en persona.
4. Las recientes actualizaciones de billetera agregan soporte para el nuevo protocolo de pago que brinda mayor seguridad, autenticación de la identidad de un receptor mediante certificados X.509 y otras características importantes como reembolsos.
Advertencia: Se debe tener especial cuidado para evitar el robo de los pagos recibidos. En particular, las claves privadas no deben almacenarse en servidores web, y las solicitudes de pago deben enviarse a través de HTTPS u otros métodos seguros para evitar que los ataques de intermediarios reemplacen su dirección de Bitcoin con la dirección del atacante.
Texto sin formato
Para especificar una cantidad directamente para copiar y pegar, debe proporcionar la dirección, la cantidad y la denominación. También se puede especificar un tiempo de vencimiento para la oferta. Por ejemplo:
(Nota: todos los ejemplos de esta sección utilizan direcciones de testnet).
Paga: mjSk1Ny9spzU2fouzYgLqGUD8U41iR35QN
Cantidad: 100 BTC
Debe pagar antes del: 2014-04-01 a las 23:00 UTC
Indicar la denominación es fundamental. En el momento de escribir este artículo, el popular software de billetera de Bitcoin tiene como valor predeterminado montos denominados en bitcoins (BTC), milibitcoins (mBTC) o microbitcoins (uBTC, "bits"). La elección entre cada unidad es ampliamente compatible, pero otro software también permite a sus usuarios seleccionar montos de denominación de algunos preseleccionados (por ejemplo, la Tabla a continuación) o todos los 8 lugares decimales estándar:
Unidad de Bitcoins (abreviatura)
1.0 bitcoin (BTC)
0,01 bitcent (cBTC)
0,001 milibitcoin (mBTC)
0.000001 microbitcoin (uBTC, "bits")
0.0000001 finney
0,00000001 satoshi
bitcoin: URI
El esquema de URI “bitcoin:” definido en BIP21 elimina la confusión de denominación y evita que el gastador copie y pegue dos valores separados. También permite que la solicitud de pago proporcione información adicional al gastador. Un ejemplo:
bitcoin: mjSk1Ny9spzU2fouzYgLqGUD8U41iR35QN? cantidad = 100
Solo se requiere la dirección, y si es lo único que se especifica, las billeteras completarán previamente una solicitud de pago con ella y permitirán que el gastador ingrese una cantidad. La cantidad especificada siempre está en bitcoins decimales (BTC).

Otros dos parámetros son ampliamente compatibles. El parámetro "etiqueta" se utiliza generalmente para proporcionar al software de billetera el nombre del destinatario. El parámetro "mensaje" se utiliza generalmente para describir la solicitud de pago al gastador. Tanto la etiqueta como el mensaje se almacenan comúnmente en el software de billetera del gastador, pero nunca se agregan a la transacción real, por lo que otros usuarios de Bitcoin no pueden verlos. Tanto la etiqueta como el mensaje deben estar codificados en URI.
Los cuatro parámetros utilizados juntos, con la codificación URI adecuada, se pueden ver en el ejemplo de línea envuelto a continuación.
bitcoin: mjSk1Ny9spzU2fouzYgLqGUD8U41iR35QN \
? cantidad = 0.10 \
& label = Ejemplo + Comerciante \
& mensaje = Pedido + de + flores +% 26 + bombones
El esquema de URI se puede ampliar, como se verá en la sección de protocolo de pago a continuación, con nuevos parámetros opcionales y obligatorios. En el momento de escribir este artículo, el único parámetro de uso generalizado además de los cuatro descritos anteriormente es el parámetro "r" del protocolo de pago.
Los programas que aceptan URI en cualquier forma deben solicitar permiso al usuario antes de pagar, a menos que el usuario haya desactivado explícitamente la solicitud (como podría ser el caso de los micropagos).
Códigos QR
Los códigos QR son una forma popular de intercambiar "bitcoin:" URI en persona, en imágenes o en videos. La mayoría de las aplicaciones móviles de billetera Bitcoin y algunas billeteras de escritorio admiten el escaneo de códigos QR para llenar previamente sus pantallas de pago.
La siguiente figura muestra el mismo código URI “bitcoin:” codificado como cuatro códigos QR de Bitcoin diferentes en cuatro niveles de corrección de errores diferentes. El código QR puede incluir los parámetros de "etiqueta" y "mensaje", y cualquier otro parámetro opcional, pero se omitieron aquí para mantener el código QR pequeño y fácil de escanear con cámaras móviles inestables o de baja resolución.





Códigos QR de Bitcoin
La corrección de errores se combina con una suma de verificación para garantizar que el código QR de Bitcoin no se pueda decodificar correctamente con datos faltantes o alterados accidentalmente, por lo que sus aplicaciones deben elegir el nivel apropiado de corrección de errores en función del espacio que tiene disponible para mostrar el código. La corrección de daños de bajo nivel funciona bien cuando el espacio es limitado, y la corrección de daños de nivel de cuartiles ayuda a garantizar un escaneo rápido cuando se muestra en pantallas de alta resolución.
Protocolo de pago
Advertencia: el protocolo de pago se considera obsoleto y se eliminará en una versión posterior de Bitcoin Core. El protocolo tiene múltiples fallas de diseño de seguridad y fallas de implementación en algunas billeteras. Los usuarios comenzarán a recibir advertencias de obsolescencia en Bitcoin Core versión 0.18 cuando usen BIP70 URI. Los comerciantes deben pasar de BIP70 a opciones más seguras como BIP21. Los comerciantes nunca deben exigir pagos BIP70 y deben proporcionar alternativas BIP21.
Bitcoin Core 0.9 es compatible con el nuevo protocolo de pago. El protocolo de pago agrega muchas características importantes a las solicitudes de pago:
• Admite certificados X.509 y cifrado SSL para verificar la identidad de los receptores y ayudar a prevenir ataques de intermediarios.
• Proporciona más detalles sobre el pago solicitado a los gastadores.
• Permite a los gastadores enviar transacciones directamente a los receptores sin pasar por la red peer-to-peer. Esto puede acelerar el procesamiento de pagos y funcionar con funciones planificadas, como las tarifas de transacción del niño paga por el padre y los pagos basados en NFC o Bluetooth fuera de línea.
En lugar de que se les pida que paguen una dirección sin sentido, como "mjSk1Ny9spzU2fouzYgLqGUD8U41iR35QN", se les pide a los gastadores que paguen la descripción del Nombre común (CN) del certificado X.509 del receptor, como "www.bitcoin.org".
Para solicitar el pago mediante el protocolo de pago, utilice un URI extendido (pero compatible con versiones anteriores) "bitcoin:". Por ejemplo:
bitcoin: mjSk1Ny9spzU2fouzYgLqGUD8U41iR35QN \
? cantidad = 0.10 \
& label = Ejemplo + Comerciante \
& mensaje = Pedido + de + flores +% 26 + chocolates \
& r = https: //example.com/pay/mjSk1Ny9spzU2fouzYgLqGUD8U41iR35QN
Ninguno de los parámetros proporcionados anteriormente, excepto "r", es obligatorio para el protocolo de pago, pero sus aplicaciones pueden incluirlos para compatibilidad con programas de billetera que aún no manejan el protocolo de pago.
El parámetro "r" le dice a los programas de billetera que tienen en cuenta el protocolo de pago que ignoren los otros parámetros y obtengan una PaymentRequest de la URL proporcionada. El navegador, el lector de códigos QR u otro programa que procesa el URI abre el programa de billetera Bitcoin del gastador en el URI.





Protocolo de pago BIP70
El protocolo de pago se describe en profundidad en BIP70, BIP71 y BIP72. Un ejemplo de programa CGI y una descripción de todos los parámetros que se pueden utilizar en el Protocolo de pago se proporcionan en la subsección Protocolo de pago de ejemplos de desarrollador. En esta subsección, describiremos brevemente en formato de historia cómo se usa normalmente el Protocolo de pago.
Charlie, el cliente, está comprando en un sitio web dirigido por Bob, el empresario. Charlie agrega algunos artículos a su carrito de compras y hace clic en el botón "Pagar con Bitcoin".
El servidor de Bob agrega automáticamente la siguiente información a su base de datos de facturas:
• Los detalles del pedido de Charlie, incluidos los artículos pedidos y la dirección de envío.
• Un pedido total en satoshis, quizás creado al convertir precios en fiat a precios en satoshis.
• Un tiempo de vencimiento en el que ese total ya no será aceptable.
• Un guión pubkey al que Charlie debe enviar el pago. Normalmente será un script de clave pública P2PKH o P2SH que contiene una clave pública secp256k1 única (nunca antes utilizada).
Después de agregar toda esa información a la base de datos, el servidor de Bob muestra un URI de "bitcoin:" para que Charlie haga clic para pagar.
Charlie hace clic en el URI "bitcoin:" en su navegador. El controlador de URI de su navegador envía el URI a su programa de billetera. La billetera conoce el Protocolo de pago, por lo que analiza el parámetro "r" y envía un HTTP GET a esa URL en busca de un mensaje PaymentRequest.
El mensaje PaymentRequest devuelto puede incluir información privada, como la dirección postal de Charlie, pero la billetera debe poder acceder a ella sin usar autenticación previa, como cookies HTTP, por lo que generalmente se usa una URL HTTPS de acceso público con una parte resistente a las conjeturas. La clave pública única creada para la solicitud de pago se puede utilizar para crear un identificador único. Por eso, en el ejemplo de URI anterior, la URL de PaymentRequest contiene la dirección P2PKH: https://example.com/pay/mjSk1Ny9spzU...qGUD8U41iR35QN
Después de recibir HTTP GET a la URL anterior, el programa CGI que genera PaymentRequest en el servidor web de Bob toma el identificador único de la URL y busca los detalles correspondientes en la base de datos. Luego crea un mensaje PaymentDetails con la siguiente información:
• El importe del pedido en satoshis y el script pubkey a pagar.
• Una nota que contiene la lista de artículos pedidos, para que Charlie sepa lo que está pagando. También puede incluir la dirección postal de Charlie para que pueda verificarla.
• La hora en que se creó el mensaje PaymentDetails más la hora en que caduca.
• Una URL a la que la billetera de Charlie debe enviar su transacción completada.
Ese mensaje PaymentDetails se coloca dentro de un mensaje PaymentRequest. La solicitud de pago permite al servidor de Bob firmar toda la Solicitud con el certificado SSL X.509 del servidor. (El Protocolo de pago ha sido diseñado para permitir otros métodos de firma en el futuro). El servidor de Bob envía la solicitud de pago a la billetera de Charlie en la respuesta al HTTP GET.



Bitcoin Core que muestra una solicitud de pago validada
La billetera de Charlie recibe el mensaje PaymentRequest, verifica su firma y luego muestra los detalles del mensaje PaymentDetails a Charlie. Charlie acepta pagar, por lo que la billetera construye un pago al script de clave pública proporcionado por el servidor de Bob. A diferencia de un pago tradicional de Bitcoin, la billetera de Charlie no transmite necesariamente automáticamente este pago a la red. En su lugar, la billetera crea un mensaje de pago y lo envía a la URL proporcionada en el mensaje PaymentDetails como un POST HTTP. Entre otras cosas, el mensaje de pago contiene:
• La transacción firmada en la que Charlie le paga a Bob.
• Una nota opcional que Charlie puede enviar a Bob. (No hay garantía de que Bob lo lea).
• Una dirección de reembolso (escritura de clave pública) que Bob puede pagar si necesita devolver algunos o todos los satoshis de Charlie.
El servidor de Bob recibe el mensaje de Pago, verifica que la transacción paga la cantidad solicitada a la dirección proporcionada y luego transmite la transacción a la red. También responde al mensaje HTTP POSTed Payment con un mensaje PaymentACK, que incluye una nota opcional del servidor de Bob agradeciendo a Charlie por su patrocinio y proporcionando otra información sobre el pedido, como la fecha de llegada prevista.
La billetera de Charlie ve el PaymentACK y le dice a Charlie que el pago ha sido enviado. PaymentACK no significa que Bob haya verificado el pago de Charlie (consulte la subsección Verificación de pago a continuación), pero sí significa que Charlie puede hacer otra cosa mientras se confirma la transacción. Una vez que el servidor de Bob verifica en la cadena de bloques que la transacción de Charlie se ha confirmado adecuadamente, autoriza el envío del pedido de Charlie.
En el caso de una disputa, Charlie puede generar un recibo comprobado criptográficamente a partir de la información firmada o comprobada de otro modo.
• El mensaje PaymentDetails firmado por el servidor web de Bob demuestra que Charlie recibió una factura para pagar una secuencia de comandos pubkey especificada por un número específico de satoshis para los productos especificados en el campo memo.
• La cadena de bloques de Bitcoin puede probar que al script pubkey especificado por Bob se le pagó el número especificado de satoshis.
Si es necesario emitir un reembolso, el servidor de Bob puede pagar de forma segura el script de devolución a pubkey proporcionado por Charlie. Ver la sección Reembolsos