Summary

  • RFC 3538 assigned 20, 40, 60, 80 and 100 to the creation or processing of successive SET messages inside an IOTP bridge. The numbers described interface progress, not fractions of commercial completion.
  • At 100, PRes could report either approved authorization or successful capture; CompletedOK could later become Failed after cancellation, while settlement and physical delivery remained outside the meter’s proof.

Imagine an operations console with a reassuring bar at its right edge. The customer has crossed the checkout, the payment handler has answered, and the display says complete. Which proposition is now true? That a request was authorized? That value was captured? That banks settled? That a warehouse released goods? That no one can cancel? RFC 3538’s answer was less theatrical and more useful: the SET-to-IOTP bridge had processed its last mapped message.

Published in June 2003 as Informational, RFC 3538 supplemented version 1.0 of the Internet Open Trading Protocol. IOTP tried to give electronic commerce a common framework while letting particular payment systems travel through a payment API. The supplement described how Secure Electronic Transaction messages would fit that interface. Its historical importance is not proof that SET/IOTP conquered commerce; the frozen record provides no named deployment or adoption measure. It is the care with which a seemingly final status remained local to its mechanism.

Section 8.12 offers the cleanest diagram. After the first SET Initiation Response is created or processed, PercentComplete becomes 20. PinitReq maps to 40, PinitRes to 60, PReq to 80 and PRes to 100. Consumer and Payment Handler observe creation and processing from opposite sides. The first initiation phase can contain a variable number of messages, yet the first response still receives 20. This is not a stopwatch or a measurement of equal work. It is an interface designer’s sequence of landmarks.

The meaning of the last landmark is deliberately plural. When the bridge handles PRes, one successful case is authorizationPerformed with an approved authorization code. Another is capturePerformed with a successful capture code. Authorization and capture are not synonyms: permission to proceed and the later collection operation occupy different commercial moments. The same envelope type and the same 100 value can therefore close two different journeys.

The state machine further resists the seduction of final language. On the Payment Handler side, an in-progress transaction can reach CompletedOK. Yet RFC 3538 explicitly permits CompletedOK to move to Failed when a change-state or cancellation operation cancels the payment. “Completed” is a scoped state at a recorded time, not a metaphysical guarantee. A system that throws away the transition history turns a reversible checkpoint into invented finality.

Receipt handling supplies a sharper warning. The CheckPayReceipt function does not especially check the Payment Receipt Information; it sends a general response as long as the request message is valid. That can be perfectly correct for an API contract. It becomes misleading only when a product renames syntactic acceptance as commercial verification. Valid envelope, recognized receipt container and verified underlying claim are three different receipts.

Delivery sits beyond the payment bridge. For physical goods, the document recommends omitting IOTP Delivery Exchanges. A delivery inquiry location may be specified, while inquiry about credit authorization between handlers can occur outside IOTP. For digital goods, authorization should be processed in real time. These choices draw responsibility boundaries. A completed payment-message path neither moves a parcel nor proves that a download reached its reader.

Inquiry and error handling preserve similar distinctions. SET Inquiry Initiation is omitted, while request and response messages are embedded in IOTP payment-scheme data. Bridge technical errors use HardError; business failure is reported through a different route, including the PRes status. An operator must retain which layer emitted the error. Otherwise a transportable business refusal looks like a broken bridge, or a technically sound bridge looks like a successful sale.

This boundary differs from the retained RFC 3354 history, which owns IOTP v2 requirements and composition versus commercial authorization, and from the RFC 3504 history, which owns corrected IOTP grammar, identity, inquiry and the broad payment/settlement/delivery separation. RFC 3538 contributes the concrete instrument panel: a five-number ladder, a dual-purpose last message and a post-completion cancellation edge.

The enduring design rule is simple. Every progress indicator needs a named denominator. Record the exact message created or processed, the actor that observed it, the completion code inside it and every later state transition. Then a full bar becomes valuable evidence. Without that provenance, 100 is merely a shape capable of borrowing certainty from events it never measured.

Sources