PaymentDetails

PaymentDetails era la parte que el comerciante firmaba realmente, y el sobre exterior solo llevaba el certificado que lo acreditaba. Tenía siete campos: un nombre de red con main como valor predeterminado, una lista de salidas, una marca de tiempo obligatoria, una expiración opcional, un memo, una URL de retorno y una cadena de bytes opaca merchant_data. Hoy un URI BIP21 más una página de pago hacen el mismo trabajo sin firma y sin servidor.

Cómo funciona

Estado: histórico. Bitcoin Core eliminó el BIP70 en la versión 0.20.0 el 3 de junio de 2020, y PaymentDetails no tiene ninguna implementación activa. Este sitio lo documenta porque los nombres de los campos siguen apareciendo en viejas guías de integración y en la referencia para desarrolladores de bitcoin.org.

La estructura viajaba en Protocol Buffers, no en JSON. Esa elección importaba por una razón en la que vale la pena detenerse: el comerciante serializaba PaymentDetails en una cadena de bytes y colocaba esos bytes exactos dentro del mensaje PaymentRequest exterior como un campo opaco, no como un mensaje anidado. La firma cubría la cadena de bytes, así que ninguna biblioteca que volviera a codificar los mismos campos en otro orden podía invalidar una firma válida.

Los siete campos se dividían en instrucciones y contabilidad.

• network, una cadena de caracteres cuyo valor predeterminado es "main", con "test" como único otro valor definido.
• outputs, una lista repetida en la que cada elemento empareja un monto en satoshis con un script. Se permitía más de una salida, y los comerciantes lo aprovechaban para repartir un único pago del cliente entre una billetera caliente y el almacenamiento en frío sin pedir al cliente que enviara dos veces.
• time, una marca de tiempo Unix obligatoria que registra cuándo se creó la solicitud.
• expires, una marca de tiempo Unix opcional a partir de la cual se suponía que la billetera debía rechazar la solicitud. Este es el campo que hacía que el BIP70 pareciera un terminal de pago con tarjeta, porque el comerciante podía cotizar un precio en fiat y garantizarlo durante un plazo fijo.
• memo, una nota UTF-8 que se mostraba al pagador.
• payment_url, adonde la billetera enviaba su mensaje Payment después de difundir la transacción.
• merchant_data, bytes opacos que se devolvían intactos para que el comerciante pudiera asociar un pago a un carrito de compra.

Solo time y los scripts de las salidas eran obligatorios. Todo lo demás podía omitirlo el comerciante, y la mayoría lo hacía.

Dónde aparece

La idea detrás de PaymentDetails sobrevivió al mensaje, y eso es lo que conviene observar.

Hoy la caducidad del precio se gestiona en el exchange y no en su billetera. Si compra desde una pantalla de compra instantánea, obtiene un precio cotizado con un temporizador al lado; si deja que el temporizador llegue a cero, la cotización se rehace al nuevo precio. Es expires reimplementado en una aplicación web, y protege al vendedor de la volatilidad exactamente del mismo modo. El emparejamiento de órdenes en el libro de órdenes de un exchange hace el mismo trabajo de otra manera: nunca cotiza un precio fijo.

Del lado del comerciante, el equivalente del mensaje completo es un registro de factura en el software de cobro. BTCPay Server y herramientas similares generan un URI BIP21, lo mantienen abierto durante un número de minutos configurado y concilian la transacción entrante con un identificador interno del pedido, que es precisamente para lo que servía merchant_data.

PaymentDetails frente a recibo

PaymentDetails era la solicitud; el recibo en el BIP70 era el mensaje PaymentACK que el comerciante devolvía después. Uno describía lo que debía ocurrir; el otro confirmaba que el comerciante había visto que ocurría. Ninguno era un hecho de la blockchain, y esa es la limitación que la gente subestimó: un acuse de recibo firmado por un comerciante demuestra que el servidor del comerciante dijo algo, no que una transacción se confirmara. Son las confirmaciones, no los recibos, las que liquidan un pago en bitcoin.