15 Steps, 2–3 Hours of Real Work, 5–15 Days of Waiting

That's what AS2 partner onboarding looks like. The technical work is straightforward. The coordination between two organizations — emails, spreadsheets, phone tag — is what kills your timeline.

This guide covers every step in order. Follow it exactly and you'll dodge the mistakes that add weeks to the process. Skip ahead, and you'll learn why everyone else follows the order.

Phase 1: Information Exchange

Don't touch your AS2 configuration yet. Both sides need to swap technical details first. Build a Partner Configuration Sheet with these fields and send it before your first call.

What You Send to Your Partner

Your AS2 ID — Case-sensitive. No accidental spaces. Triple-check this one; a wrong AS2 ID burns more hours than any other mistake.
Your AS2 endpoint URL — The HTTPS URL receiving inbound AS2 messages. Example: https://as2.yourcompany.com/receive
Your public certificate — Your partner encrypts messages to you and verifies your MDN signatures with this.
Your MDN preference — Synchronous or asynchronous. If async, include your MDN receipt URL.
Preferred encryption algorithm — AES-256, AES-128, or 3DES. Pick AES-256 unless your partner can't support it.
Preferred signing algorithm — SHA-256, SHA-384, or SHA-512.
Troubleshooting contact — Name, email, phone. Someone who can look at logs when the first test fails. Because it will.

What Your Partner Sends to You

The same seven items, from their side. Don't configure anything until you have all seven. Missing even one guarantees a wasted round trip.

Send your partner a pre-filled template before the kickoff call. Fill in your side already. This eliminates at least one full email cycle — which, in enterprise time, means saving 2–3 days.

Phase 2: Certificate Exchange and Validation

Certificates are the #1 cause of onboarding delays. Most teams wait until configuration day to look at the cert they received two weeks ago. Don't be that team.

Step 1: Send Your Certificate

Export in PEM format — it's the most universally accepted. Send via encrypted email or a secure file-sharing service. Never send certificates over unencrypted channels. This is basic hygiene.

Step 2: Validate Their Certificate Immediately

The day it arrives. Not next week. Not during the test window. The day it arrives.

Run these three checks:

# Verify format (should print certificate details)
openssl x509 -in partner_cert.pem -text -noout

# Check expiry
openssl x509 -in partner_cert.pem -noout -enddate

# Check key size (2048-bit minimum)
openssl x509 -in partner_cert.pem -text -noout | grep "Public-Key"

If anything fails, reply with the exact problem. "Your certificate is DER-encoded; we need PEM" gets a fix in hours. "The certificate doesn't work" gets a confused reply in three days.

Step 3: Confirm Certificate Purpose

Some orgs use one cert for both encryption and signing. Others split them. Ask directly: "Is this certificate for both encryption and signing, or do you have separate certificates?"

Also ask: self-signed or CA-signed? If CA-signed, do you need the intermediate chain? Getting this wrong means a perfectly valid cert that your system refuses to trust.

Phase 3: System Configuration

You have all the details. Certificates are validated. Now configure.

Step 4: Create the Partner Profile

In your AS2 system, create a new trading partner with:

Partner AS2 ID — exactly as provided, including case. Copy-paste it. Don't retype it.
Partner endpoint URL
Their public certificate (imported)
Encryption algorithm (as agreed)
Signing algorithm (as agreed)
MDN mode — sync or async (as agreed)

Step 5: Verify Your Own Profile

Confirm your AS2 system matches what you told your partner:

Your AS2 ID is set correctly
Your endpoint URL is accessible from the public internet
Your private key is loaded and matches your public certificate
MDN signing uses the agreed algorithm

A mismatch between what you told your partner and what your system actually does is a 40-hour debugging black hole. Verify before you test.

Step 6: Network Verification

Before sending any AS2 messages, confirm basic HTTPS connectivity in both directions:

# Can you reach them?
curl -I https://partner-as2-endpoint.com/receive

# Can they reach you? (ask them to run this)
curl -I https://your-as2-endpoint.com/receive

Timeout or connection refused? Stop. Get the firewall teams involved. Give them specific IPs and ports. Don't attempt AS2 testing until raw HTTPS works both ways. Testing AS2 over a broken network generates noise, not signal.

Phase 4: Testing

Test in stages. Each stage must pass before the next one starts.

Step 7: Self-Test First

Before your partner gets involved, test against an endpoint you control. This proves your system can:

Establish a TLS connection
Send a properly formatted AS2 message
Encrypt and sign correctly
Process an incoming MDN

Every issue you find and fix yourself saves a round trip with your partner. That's 1–2 business days per issue. Fix your own problems first.

Step 8: Send a Test Message to Your Partner

Schedule a specific test window. Someone on their side needs to be watching logs. Firing off a test at midnight their time and waiting for a reply is how onboarding stretches to three weeks.

Send a small payload — an EDI 997 or a plain text file. You're validating the AS2 transport, not the business content.

After sending, check immediately:

Did you get an MDN? (Sync: check inbox. Async: check receipt endpoint logs.)
MDN status: "processed" or "failed"?
Did the MIC verify correctly?

Step 9: Receive a Test Message from Your Partner

Reverse direction. Have your partner send to you. Verify:

Message arrived at your endpoint
Decryption succeeded
Signature validated
Your system returned an MDN

Step 10: End-to-End with Real Payloads

Send a production-realistic EDI document — full size, real content type, actual character encoding. Have your partner confirm they can process it. Have them send one back.

This catches everything that small test files miss: content-type mismatches, encoding problems, payload-size limits, and processing rules that only fire on real data. Don't skip this step. It exists because people skipped it and regretted it in production.

Phase 5: Go-Live

Step 11: Document Everything

Before flipping to production, record the final configuration:

Both AS2 IDs
Both endpoint URLs
Certificate details — subject, issuer, expiry date, serial number
Encryption and signing algorithms
MDN mode and receipt URL (if async)
Date of last successful test
Contact info for both sides

Store this where your ops team can find it. In 11 months, when the certificate expires and nobody remembers who to call, this document is worth its weight in gold.

Step 12: Set Up Monitoring

Configure alerts for:

Failed deliveries — HTTP errors, timeouts
MDN failures — verification errors, missing MDNs
Certificate expiry warnings — 90, 60, and 30 days out
Volume anomalies — a sudden drop in messages usually means a broken connection, not a slow business day

Monitoring without alerting is just logging. Make sure someone gets paged.

Step 13: Go Live and Watch

Disable test mode. Route production documents through the connection. Monitor closely for the first 48 hours. The first real business day of traffic will surface anything your test payloads didn't cover.

The Delays That Burn the Most Time

"We need IT approval for the firewall rule." — Submit the firewall request on day one. Not when you're ready to test. Firewall changes take 3–7 business days at most orgs. Start the clock early.

"Our certificate expired and we need a new one." — This is why you validate the cert the day it arrives (Step 2). Finding an expired cert during the test window costs you another week minimum.

"We're not sure which AS2 ID to use." — Pre-fill your configuration template. Ambiguity about required fields is the #1 source of unnecessary email threads.

"Test messages worked, but production messages fail." — Almost always a payload size issue, a different content type, or processing rules that only trigger on real data. That's why Step 10 exists. Don't skip it.

Cut Your Onboarding Time in Half

The single biggest time-saver: test your own configuration against a known-good endpoint before involving your partner. If your side works, partner testing becomes a quick verification instead of a joint debugging session.

AS2 Certify gives you that known-good endpoint. Send your test messages. Get back a detailed report covering TLS, certificates, encryption, signing, and MDN — with a pass/fail grade on each. Run it after Step 6, before Step 8. Walk into partner testing knowing your side is solid.

The free tier includes 3 tests per month. That's enough for a standard partner onboarding. If you're running multiple onboardings in parallel, paid plans scale up from there.