You Know This Call

You're onboarding a new trading partner. Your company runs IBM Sterling. They run Cleo. Both VANs have been doing this for years. Should be routine.

It is not routine.

Two weeks in, you're on a three-way call. Your VAN says their config is correct. Your partner's VAN says the same. The test message still fails. Nobody will budge. You're the one explaining to your project manager why a "standard AS2 connection" is two weeks late.

This plays out the exact same way, at the exact same pace, across thousands of onboardings every year. The root cause is almost always a five-minute fix. The process to find it takes 15 business days.

The Email Chain From Hell

Every VAN-to-VAN onboarding follows this script. You've probably lived some version of it.

Day 1: Submit the Request

You open a partner onboarding ticket with your VAN. Attach the AS2 ID, endpoint URL, and encryption preferences. You feel productive. This won't last.

Day 3: Missing Information

Your VAN responds. They need the partner's public certificate and AS2 ID. You already submitted the AS2 ID. They want it again in a different form field. Fine.

Day 4: The Out-of-Office Wall

You email your partner's IT contact requesting their certificate. Auto-reply: "Out of office until Monday. For urgent requests, contact..." You contact the backup. No response.

Day 7: The Certificate Arrives

Your partner's IT contact is back. They send the certificate. You forward it to your VAN. Progress. Finally.

Day 9: Wrong Format

Your VAN replies: "The certificate is in DER format. We need PEM." You stare at the email. They could convert this themselves with one OpenSSL command. They won't. You email your partner again.

Day 10: Waiting

You follow up. Your partner's IT person is "checking with their security team" about exporting in PEM format. You drink coffee and update the project timeline.

Day 12: Second Certificate

New cert arrives. PEM this time. You forward it to your VAN. They configure it within a few hours. You schedule the first test message for tomorrow morning. Optimism returns briefly.

Day 13: First Test, First Failure

Test message sends. Payload arrives at the partner's endpoint. The MDN comes back. Your VAN rejects it. Error: "MDN signature verification failed." Your VAN says the partner's signing algorithm is wrong. You relay this to the partner's VAN. They respond within the hour: "Our configuration is correct."

Two VANs. Two claims of correctness. One broken connection.

Day 15: The Three-Way Call

You schedule a call with both VANs. Thirty minutes of hold music. Forty-five minutes of finger-pointing. Your VAN's engineer reads the MDN headers. The partner's VAN engineer reads their logs. Nobody can reproduce the issue live because "the test environment is down for maintenance."

The call ends with action items. Both sides will "review their configuration and follow up by EOD." They will not follow up by EOD.

The Actual Problem

Your VAN signs MDNs with SHA-256. Your partner's VAN signs MDNs with SHA-1. Your system expects SHA-256 on incoming MDNs and rejects SHA-1 signatures.

That's it. One algorithm mismatch. One configuration dropdown. A two-minute change on either side.

Neither VAN checked the signing algorithm before configuring the connection. Neither VAN asked what the other side expected. Both assumed their defaults were universal. Both were wrong.

SHA-1 versus SHA-256 is the single most common MDN failure we see across VAN-to-VAN connections. It accounts for roughly 30% of all "our side is fine" disputes. The second most common: sync versus async MDN disagreements. Third: mismatched encryption algorithms. All of them are trivially identifiable if you know where to look before day one.

Fifteen business days. Three to five email round trips per issue. Eight to fifteen business days of calendar time. For a config value you could have identified in minutes.

What You Should Have Done

Before either VAN touched a configuration screen, run an independent diagnostic against both endpoints.

Not a test message. A diagnostic. There's a difference.

A test message tells you pass or fail. A diagnostic tells you what each endpoint supports, expects, and is configured to do. It answers the questions that take 15 days to answer over email:

What signing algorithms does each side support?
What does each side expect on inbound MDNs?
Sync or async MDN? Do both sides agree?
What encryption algorithm is each side configured for?
Are the certificates valid, unexpired, and in the right format?
Is TLS configured consistently on both endpoints?

Get these answers first. Compare them side by side. Identify mismatches before the first onboarding email goes out. Hand both VANs a specification, not a hope.

You wouldn't deploy code without running tests. Don't onboard a trading partner without running diagnostics.

How AS2 Certify Fits

Configure both endpoints in AS2 Certify: your VAN's AS2 endpoint and your partner's VAN's AS2 endpoint. Run the connection comparison. You get a report in minutes showing exactly what each side supports and where they disagree.

The report is specific. Not "MDN configuration mismatch." It tells you: "Your endpoint signs MDNs with SHA-256. Partner endpoint signs MDNs with SHA-1. Partner endpoint does not support SHA-256 for MDN signing." Actionable. Forwardable.

Send that report to both VANs. Attach it to the onboarding ticket. Now the conversation starts with facts instead of finger-pointing. Your VAN sees the exact mismatch. Your partner's VAN sees it too. The fix takes minutes because the diagnosis already happened.

No three-way calls. No "our side is fine" dead ends. No 15-day email chains.

The Real Cost

Run the numbers on a single VAN-to-VAN onboarding gone wrong.

Direct labor: 2 integration engineers, 8 hours each of coordination, troubleshooting, and waiting on responses. At $150/hour, that's $4,800.

VAN support costs: Most VANs charge for onboarding assistance or consume support hours from your contract. A standard onboarding ticket costs $200 to $500 in VAN support fees. Two VANs means double that.

Business impact: 15 business days is three calendar weeks. Three weeks your trading partner can't send orders. Three weeks of manual data entry or phone-based ordering as a workaround. Three weeks of delayed invoicing on the other end.

Opportunity cost: Your integration engineers spent 16 hours on one partner. Most teams onboard 8 to 15 new partners per year. At this rate, partner onboarding alone consumes 128 to 240 hours of engineering time annually. That's 6 to 10 weeks of full-time work, mostly spent waiting for email replies.

Multiply the $4,800 by 10 partners. That's $48,000 a year in labor costs for a process that should take two hours per partner.

The math doesn't need commentary.

Pre-Onboarding Checklist

Run through this before you send your first onboarding email. Ten minutes of verification eliminates days of back-and-forth.

Collect both AS2 IDs. Verify exact spelling, case, and whitespace. Copy-paste from official documentation only.
Exchange certificates early. Request PEM format explicitly. Verify the certificate is not expired. Check key size (2048-bit minimum).
Agree on MDN type. Sync or async. Get it in writing. If async, confirm both receipt URLs are reachable from the other network.
Agree on MDN signing algorithm. SHA-256. Put it in the onboarding spec. Both sides.
Confirm encryption algorithm. AES-256 or 3DES. Both sides must match.
Verify TLS compatibility. TLS 1.2 minimum on both endpoints. Test with openssl s_client before submitting the VAN ticket.
Test firewall connectivity. Confirm both endpoints are reachable on the expected ports from both networks.
Run an independent diagnostic. Use AS2 Certify or equivalent tooling to verify both endpoints before either VAN starts configuration.
Document everything in one spec. One document. Both sides' configurations. Every parameter. Send it to both VANs with the onboarding request.

Your VANs won't do this work for you. They configure what you tell them to configure. Tell them the right thing the first time.