SOAP API is a web service interface that exchanges structured XML messages under the SOAP protocol, with operations and data types fixed in advance in a machine-readable WSDL contract. SOAP once stood for Simple Object Access Protocol, an expansion the W3C dropped with version 1.2 in 2003. Each message has an Envelope, an optional Header for security tokens or transaction IDs, and a Body holding the operation call or a Fault element. Unlike REST, it models operations such as SubmitPayment rather than resources. WS-Security adds message-level encryption and signatures, which suits regulated settings, but messages are several times larger than JSON. Core banking systems and older payment gateways still expose SOAP endpoints, making SOAP-only dependencies a technical-debt item in acquisitions.
What is SOAP API, compared with a plain web request
Where a REST API treats data as resources at URLs, SOAP treats it as operations: `GetBalance`, `SubmitPayment`, `CancelTransfer`. Every request and response is an XML document, and the service publishes a WSDL (Web Services Description Language) file listing each operation, its inputs, outputs and fault types. Client code can be generated directly from the WSDL, which is why SOAP integrations in Java and .NET often need little hand-written parsing.
SOAP is transport-independent. It usually runs over HTTP POST, but the same message can travel over message queues or even email.
How does SOAP API work
A message has a fixed structure. The Envelope wraps everything. An optional Header carries metadata such as security tokens, transaction IDs or routing information. The Body holds the operation call and its parameters. If something goes wrong, the Body instead contains a Fault element with a code, a reason and detail.
A payment request might send `SubmitPayment` with amount 250.00, currency EUR and a beneficiary IBAN inside the Body, and a signed timestamp in the Header. The server validates the XML against the schema before business logic runs, so malformed input fails early with a precise fault rather than a generic 400 error.
Security and reliability extensions
The WS-* family of standards is SOAP's main advantage in regulated settings. WS-Security adds message-level encryption and XML signatures, so a message stays protected and attributable even after passing through intermediaries, not just while in transit over TLS. WS-ReliableMessaging and WS-AtomicTransaction address guaranteed delivery and coordinated commits.
The cost is weight. A SOAP message is several times larger than the equivalent JSON, and parsing XML with signatures consumes more CPU, which matters at card-authorization volumes.
Where SOAP still runs in payments
SOAP was the default for enterprise integration through the 2000s, and much of that infrastructure is still live. Core banking systems, older payment gateway integrations, card management platforms and some government tax and customs services expose SOAP endpoints, sometimes with a REST facade added later.
For an acquirer of a payment business, a dependency on a provider's SOAP-only interface is a technical-debt item worth pricing: migrations typically mean rewriting integration code, regenerating test suites, and running both interfaces in parallel until partners switch.