AS2 and OFTP2

AS2 and OFTP2 exchange EDI directly over the internet with cryptographic signing and encryption, rather than through an intermediary. Retail and automotive partners commonly require one of them.

What they need

Both are certificate-based. For each partner you hold their public certificate, used to encrypt what you send and verify what they sign, and your own key pair, used to sign what you send and decrypt what you receive.

Receipts

AS2 uses an MDN — a signed receipt confirming a message arrived and verified. A signed MDN is meaningful evidence of delivery, which is why partners rely on it commercially. Configure whether MDNs are synchronous or asynchronous to match what the partner expects.

Private key material

Your private key has to be stored, because it is needed at the moment a message is sent. It is held with the partner configuration, and the field is hidden from the ordinary datastore editor so it is not displayed casually.

Be clear about what that does and does not mean. It prevents the key being shown on a normal admin screen. It does not encrypt it beyond the platform's usual protections, so anyone with database access has it — the same exposure as every other credential the platform stores. Treat database access accordingly, and keep the number of people with it small.

Certificates expire

This is the most common cause of a working AS2 link failing. Certificates typically last one to three years and then stop, usually without warning to anyone watching the right screen.

Diary the expiry of both your own certificate and every partner's when you configure them. Renewal has to be coordinated — the partner must load your new certificate before you start signing with it — so start weeks ahead, not days.

Going live

Both transports ship disabled. Enable, exchange test messages in both directions, confirm receipts arrive and verify, and only then switch production traffic. Keep the previous route available until you have seen a full cycle succeed.