972-836-7750 Request a Demo Talk to an EDI/API Expert Search
    See all results Browse the sitemap Tip: press / to search from any page
    Talk to an EDI/API Expert Request a Demo Call Sales 972-836-7750

    B2B communication protocols

    AS2: secure, receipted EDI over the internet

    AS2 is the most widely used way to send EDI documents directly to trading partners over the internet. It encrypts and signs each message and returns a signed receipt, so both sides can prove what was sent and received. ECOM's communication team sets up, tests and monitors AS2 connections with every partner.

    Specification
    IETF RFC 4130 (EDIINT AS2)
    Transport
    HTTP or HTTPS (HTTP POST)
    Message security
    S/MIME encryption and digital signatures
    Proof of delivery
    MDN receipts, signed and with a MIC
    Talk to an EDI/API Expert
    Where AS2 fitsA hub diagram: retailers, manufacturers, distributors and healthcare partners exchange AS2 messages and MDNs with the ECOM B2B gateway, which encrypts, signs and receipts them, and passes translated documents to the ERP, warehouse, finance and other partners.Where AS2 fitsPartners, the ECOM gateway and your systemsAS2 PARTNERSRetailersManufacturersDistributorsHealthcare partnersYOUR SYSTEMSERPWarehouse (WMS)FinanceOther partnersECOM B2B gatewayAS2S/MIME encrypt and signHTTPS transportSigned MDN receipts
    Where AS2 fitsA hub diagram: retailers, manufacturers, distributors and healthcare partners exchange AS2 messages and MDNs with the ECOM B2B gateway, which encrypts, signs and receipts them, and passes translated documents to the ERP, warehouse, finance and other partners.Where AS2 fitsPartners, the ECOM gateway and your systemsAS2 PARTNERSRetailersManufacturersDistributorsHealthcare partnersECOM B2B gatewayAS2S/MIME encryptand signHTTPS transportSigned MDNreceiptsYOUR SYSTEMSERPWarehouse (WMS)FinanceOther partners

    Each partner connects directly to the gateway by AS2. Documents are protected in transit and at rest, and every transfer is receipted.

    Expand diagram Download SVG

    Overview

    What AS2 is

    AS2 (Applicability Statement 2) defines how to send a business document, such as an X12 or EDIFACT file, from one company's AS2 software to another's over HTTP. Each message is packaged with S/MIME, the same standard used for secure email, so it can be encrypted for the receiver and signed by the sender.

    When the receiver gets a message, it returns a Message Disposition Notification (MDN). A signed MDN includes a digest of the message as received, called the MIC. If it matches the sender's own calculation, the sender has evidence that the exact document arrived intact and was accepted for processing.

    Where businesses use it

    • Retail and consumer goods

      Large retailers commonly require suppliers to connect by AS2 for orders, ship notices and invoices.

    • Manufacturing and distribution

      Direct connections between manufacturers, distributors and their partners without a third-party network.

    • Healthcare, energy and finance

      Any exchange that needs encryption, proof of delivery and a direct connection.

    How it works

    How an AS2 transfer works

    The sender compresses the document if agreed, signs it with its private key, encrypts it with the receiver's public certificate, and posts it over HTTP or HTTPS to the receiver's AS2 URL. HTTP headers carry the AS2-From and AS2-To identifiers, a unique Message-ID, and the receipt the sender wants.

    The receiver decrypts the message with its private key, checks the signature with the sender's certificate, decompresses it, and returns an MDN. A synchronous MDN comes back on the same HTTP connection; an asynchronous MDN is posted later to a URL the sender provided, which suits large files and slow processing.

    AS2 HTTP headers, line by lineAnnotated AS2 HTTP request headers: POST to the AS2 URL, AS2-Version, AS2-From, AS2-To, Message-ID, Disposition-Notification-To, Disposition-Notification-Options asking for a signed receipt with SHA-256, Receipt-Delivery-Option for an asynchronous MDN, and the S/MIME content type.AS2 HTTP headers, line by linePlaceholder names and URLsPOST /as2 HTTP/1.111The message is posted to the receiver's AS2 URL.AS2-Version: 1.222AS2 version and supported features.AS2-From: SENDERAS233Sender's AS2 identifier (agreed between partners).AS2-To: RECEIVERAS244Receiver's AS2 identifier.Message-ID: <a1b2c3@sender.example>55Unique ID, used to match the MDN and catch duplicates.Disposition-Notification-To: ...66Asks for an MDN.Disposition-Notification-Options:77Asks for a signed MDN with a SHA-256 MIC. signed-receipt-micalg=...sha-25688(continuation of the options header)Receipt-Delivery-Option: https://...99Present only for an asynchronous MDN.Content-Type: application/pkcs7-mime1010The body is an encrypted S/MIME package.
    AS2 HTTP headers, line by lineAnnotated AS2 HTTP request headers: POST to the AS2 URL, AS2-Version, AS2-From, AS2-To, Message-ID, Disposition-Notification-To, Disposition-Notification-Options asking for a signed receipt with SHA-256, Receipt-Delivery-Option for an asynchronous MDN, and the S/MIME content type.AS2 HTTP headers, line by linePlaceholder names and URLsPOST /as2 HTTP/1.1The message is posted to the receiver's AS2URL.AS2-Version: 1.2AS2 version and supported features.AS2-From: SENDERAS2Sender's AS2 identifier (agreed betweenpartners).AS2-To: RECEIVERAS2Receiver's AS2 identifier.Message-ID: <a1b2c3@sender.example>Unique ID, used to match the MDN and catchduplicates.Disposition-Notification-To: ...Asks for an MDN.Disposition-Notification-Options:Asks for a signed MDN with a SHA-256 MIC. signed-receipt-micalg=...sha-256(continuation of the options header)Receipt-Delivery-Option: https://...Present only for an asynchronous MDN.Content-Type: application/pkcs7-mimeThe body is an encrypted S/MIME package.

    These headers travel with every AS2 message. They name the parties, identify the message and say what kind of receipt the sender wants.

    Expand diagram Download SVG

    An AS2 message and its signed receiptA sequence diagram: the sender signs, compresses and encrypts the document, posts it over HTTPS, the receiver decrypts it, verifies the signature and returns a signed MDN with the MIC, which the sender compares with its own.An AS2 message and its signed receiptSign, encrypt, post, verify, acknowledgeSender AS2Internet (HTTPS)Receiver AS2Sign, compress, encrypt (S/MIME)HTTP POST: AS2-From, AS2-To, Message-IDDecrypt, verify signature, compute MICSigned MDN with MIC (sync or async)Compare MIC: delivery proven
    An AS2 message and its signed receiptA sequence diagram: the sender signs, compresses and encrypts the document, posts it over HTTPS, the receiver decrypts it, verifies the signature and returns a signed MDN with the MIC, which the sender compares with its own.An AS2 message and its signedreceiptSign, encrypt, post, verify, acknowledgeSender AS2Internet(HTTPS)Receiver AS2Sign, compress,encrypt (S/MIME)HTTP POST: AS2-From,AS2-To, Message-IDDecrypt, verifysignature, computeMICSigned MDN with MIC(sync or async)Compare MIC:delivery proven

    The message is protected before it leaves the sender. The signed MDN, with the MIC, proves what the receiver got.

    Expand diagram Download SVG

    In depth

    AS2 security, receipts and operations in depth

    AS2 has several security layers that are often confused. Each one protects something different.

    • Encryption (S/MIME)

      The document is encrypted with the receiver's public certificate, so only the holder of the matching private key can read it. It stays protected end to end, including while it waits on any server in between. Current setups use AES; 3DES is an older algorithm still met with some partners and is being retired, and RC2 is obsolete and should not be used.

    • Digital signature

      The sender signs a hash of the document with its private key. The receiver checks it with the sender's certificate, which proves who sent it and that nothing changed. Signing does not hide the content; encryption does. SHA-256 or stronger is the current choice; SHA-1 and MD5 are legacy and weak.

    • TLS (HTTPS)

      TLS protects the connection between the two servers, including the AS2 headers, and can authenticate the server. It is separate from S/MIME: TLS protects the channel while the message is in transit, S/MIME protects the message itself. Many partners use both. TLS 1.2 or 1.3 should be used; TLS 1.0 and 1.1 and all SSL versions are deprecated.

    • Compression

      Large documents can be compressed before signing or encryption (AS2-Version 1.1 and later). It reduces transfer time and has to be agreed with the partner.

    • MDN receipts

      The MDN reports whether the message was processed or failed, for example with decryption-failed or authentication-failed. A signed MDN with a matching MIC gives non-repudiation of receipt: evidence the partner received exactly what you sent.

    • Synchronous or asynchronous MDN

      Synchronous receipts return on the same connection and suit most documents. Asynchronous receipts are sent later to the sender's URL and avoid timeouts on large files or slow processing.

    • Certificates

      Each party has X.509 certificates for signing and encryption, often self-signed for AS2, and a separate CA-issued certificate for its HTTPS server. Certificates expire, so each one is tracked.

    • Certificate rollover

      Before a certificate expires, the new one is sent to every partner with a change date. Partners load it in advance; on the date the new key is used for signing and decryption. Where both sides' software supports it, the old and new keys overlap for a short period to avoid failed messages.

    • Troubleshooting

      Common causes of failure: an AS2 identifier or URL mismatch, an expired or wrong certificate, a firewall or IP allow list blocking the connection, mismatched algorithms, TLS version or cipher mismatch, or a synchronous MDN timing out on a large file. Logs on both sides and the MDN text point to the cause.

    Encryption, signatures and TLS compared

    All three use certificates, but they answer different questions.

    LayerProtectsAnswers the questionCurrent choiceLegacy, with limits
    S/MIME encryptionThe document, end to endCan anyone else read it?AES (128 or 256-bit)3DES: being retired; RC2: obsolete
    S/MIME signatureThe document's integrity and originWho sent it, and was it changed?SHA-256 or strongerSHA-1 and MD5: weak
    TLS (HTTPS)The connection in transit, including headersIs the channel private and is the server genuine?TLS 1.2 or 1.3SSL, TLS 1.0 and 1.1: deprecated
    Signed MDNProof of receiptDid the partner receive exactly this?Signed, SHA-256 MICUnsigned MDN: no proof

    In practice

    Example: connecting a supplier to a retailer by AS2

    A retailer asks a new supplier to connect by AS2 before it sends its first purchase orders.

    Example: connecting a supplier to a retailer by AS2Five steps: exchange AS2 profiles, open the network, test in both directions with MDN checks, go live, then monitor and renew certificates.Example: connecting a supplier to a retailer by AS2A practical example, step by step1ExchangeprofilesBoth sidesexchange AS2identifiers, URLs,certificates,algorithms and MDNpreferences.Step 12Open thenetworkFirewalls and IPallow lists areupdated; HTTPScertificates arechecked.Step 23Test both waysTest files go eachway; MDNs andMICs are verified.Step 34Go liveProduction ordersflow in; ship noticesand invoices flowout.Step 45Monitor andrenewMissing MDNs raisealerts; certificatesare renewed beforethey expire.Step 5
    Example: connecting a supplier to a retailer by AS2Five steps: exchange AS2 profiles, open the network, test in both directions with MDN checks, go live, then monitor and renew certificates.Example: connecting a supplierto a retailer by AS2A practical example, step by step1Exchange profilesBoth sides exchange AS2 identifiers,URLs, certificates, algorithms and MDNpreferences.Step 12Open the networkFirewalls and IP allow lists areupdated; HTTPS certificates arechecked.Step 23Test both waysTest files go each way; MDNs and MICsare verified.Step 34Go liveProduction orders flow in; ship noticesand invoices flow out.Step 45Monitor and renewMissing MDNs raise alerts; certificatesare renewed before they expire.Step 5

    Most of the work is in steps one to three. After go-live, monitoring and certificate renewal keep the connection healthy.

    Expand diagram Download SVG

    Connections

    How AS2 connects your business

    • Trading partners

      Each partner gets its own AS2 profile: identifiers, URL, certificates, algorithms and MDN options.

    • EDI translation

      Received documents go straight to translation and mapping; outbound documents are sent as soon as they are mapped.

    • ERP and business systems

      Orders, ship notices and invoices flow between AS2 partners and your ERP without manual steps.

    • Monitoring

      Every message and MDN is logged, so you can show when a document was sent and received.

    ECOM

    How ECOM supports AS2

    ECOM supports AS2 with dedicated implementation, mapping, communication and support teams, and with specialists who know the industries your partners work in.

    • Implementation team

      Plans the AS2 setup with you, configures it on the gateway and runs the tests with your partners and systems.

    • Mapping team

      Builds and maintains the maps, code conversions and validation rules between partner data and your applications.

    • Communication team

      Sets up and monitors partner connections, certificates, keys and credentials, and coordinates changes with each partner.

    • Support team

      Watches the flows, investigates failed or missing documents, and works the issue through with you and your partner.

    For AS2 in particular

    • A dedicated communication team that sets up AS2 profiles, certificates, algorithms and MDN options for each partner.
    • Certificate tracking and coordinated rollovers, with partner notices sent ahead of each change date.
    • Troubleshooting of failed transfers and MDN errors with your partner's technical team.
    • Partner onboarding for AS2: exchanging connection details, testing in both directions and confirming the go-live date with each partner.
    • Monitoring of every connection, with alerts for failed, missing or unacknowledged transfers.

    Frequently asked questions

    Is AS2 encryption the same as HTTPS?

    No. HTTPS (TLS) protects the connection while the message is in transit. AS2 encryption (S/MIME) protects the document itself, end to end, and it stays encrypted until the receiver decrypts it. Many partners use both.

    What is an MDN?

    A Message Disposition Notification is the receipt the receiver returns. A signed MDN with a matching MIC proves the receiver got exactly the document you sent.

    Should we use a synchronous or asynchronous MDN?

    Synchronous MDNs are simplest and work for most documents. Asynchronous MDNs are better for large files or when processing takes time, because the HTTP connection does not have to stay open.

    What happens when an AS2 certificate expires?

    Messages signed or encrypted with an expired certificate are usually rejected. ECOM tracks expiration dates, sends the new certificate to partners ahead of time, and switches on an agreed date.

    Are 3DES and SHA-1 still acceptable?

    They are legacy algorithms. Some older partner systems still use them, and they work, but they are weaker than AES and SHA-256. ECOM recommends moving partners to current algorithms when possible.

    Related pages

    Talk to an EDI/API Expert

    Tell us which partners, systems and AS2 requirements you are working with. An ECOM specialist will review them with you and outline the setup, the maps and the tests.

    Talk to an EDI/API Expert Request a Demo