You need to prove your AS2 endpoint works before a partner go-live, after a cert renewal, or in the middle of a finger pointing standoff. AS2 has no self test mode, so you need a counterparty. Three of them cost nothing: mendelson's public test server, an OpenAS2 instance you run yourself, and AS2 Certify's free tier.

This post compares those three head to head so you can pick one. For the background on why AS2 has no self test mode and how testing against a stand-in counterparty works, read validating your AS2 setup without a partner. If the failure you are chasing is certificate related, start with the AS2 certificates guide.

All three are legitimate options. They make different tradeoffs on setup time, what gets validated, and how much interpreting the results asks of you. Here's an honest breakdown.

The three options at a glance

	mendelson test server	Your own OpenAS2 instance	AS2 Certify
What it is	Public AS2 endpoint run by mendelson	Open source AS2 server you deploy as a second endpoint	Hosted automated tester with graded report
Cost	Free	Free software; your server and time	Free tier; paid plans for more
Setup time	Under an hour (partner config on your side)	Several hours to a few days	Minutes
Result format	Raw MDNs and logs you inspect manually	Raw logs on both ends, you correlate them	A to F graded report, pass/fail per check
TLS validation	Exercised, not analyzed for you	Exercised, you read the handshake logs	Checked and reported explicitly
Certificate checks	Implicit (exchange fails if wrong)	Implicit, plus whatever you inspect	Expiry, chain, and role checked explicitly
Encryption / signing	Validated by successful exchange	Validated by successful exchange	Validated and itemized per algorithm check
MDN round trip	Yes, you verify it by reading the MDN	Yes, you verify it in logs	Yes, verified and graded automatically
Second endpoint needed	No (they are the endpoint)	Yes, you build and run it	No

Option 1: mendelson's public test server

mendelson, the company behind a well known open source AS2 implementation, runs a public test server anyone can exchange messages with. You register, configure it as a trading partner in your own AS2 software, exchange certificates, and send.

Strengths. It's been around for years and the EDI community trusts it. It's a real, independently operated AS2 endpoint, which is exactly what a meaningful test requires. It costs nothing, and configuring it exercises the same partner setup workflow you'll repeat with real partners, which has training value in itself. If your message decrypts on their end and you get a signed MDN back, your outbound path genuinely works.

Limits. The output is raw material, not a diagnosis. You get MDNs and log lines; turning those into "my signing algorithm is wrong" or "my chain is missing an intermediate" is on you. There's no graded report to forward to a partner, no explicit TLS analysis, and no itemized list of what passed and failed. If the exchange fails, you're back to interpreting AS2 error messages, which is the skill you were hoping to shortcut. It also primarily tells you about the specific configuration you set up against mendelson's published parameters, so a mismatch that only exists between you and your real partner won't surface.

Pick it when you're comfortable reading AS2 logs, you want a free independent counterparty, and you have time to interpret results yourself.

Option 2: run your own OpenAS2 instance as a test partner

OpenAS2 is a mature open source AS2 server. Stand one up on a second machine (or a cloud VM), configure it as a fake trading partner, and exchange messages between it and your production endpoint.

Strengths. Total control. You can simulate any partner configuration you want: force SHA-256 signing, switch encryption algorithms, test async MDNs to an arbitrary return URL, break things on purpose to see what your monitoring catches. You see logs from both sides of the exchange, which no external service gives you. For teams that onboard many partners with wildly varying requirements, a permanent in house test endpoint pays for itself. It's also the only option here that works entirely inside your own network, if that matters for your security posture.

Limits. The setup burden is real. You're installing Java, editing XML partner configs, generating and exchanging test certificates, opening firewall ports, and debugging the test rig before you can debug your actual problem. Expect several hours if you've done it before and days if you haven't (our OpenAS2 setup tutorial covers the process). There's a subtler problem too: a test partner you configured yourself shares your assumptions. If you misunderstand how certificate roles work, you'll misconfigure both ends the same way, the exchange will succeed, and the test will tell you nothing. An independent counterparty catches the mistakes you can't see; your own instance often can't.

Pick it when you need to simulate specific partner configurations repeatedly, you want both sides' logs, or your testing must stay inside your network.

Option 3: AS2 Certify

Full disclosure: this is our product, so weigh this section accordingly. Here's what it does and doesn't do.

Strengths. You point it at your endpoint and it runs an automated round trip: TLS handshake analysis, certificate expiry and chain validation, encryption, signing verification, and MDN handling, eight checks in about 60 seconds. The output is a graded A to F report with pass/fail and specifics per check, so "signed with SHA-1, partner requires SHA-256" arrives as a finding, not as a log line you had to hunt for. No second endpoint to build, no partner config to write, and the report is a neutral artifact you can attach to the email when your partner insists the problem is on your side. The basic connection test is free, no account needed, and there's a standalone certificate checker for quick cert sanity checks.

Limits. It tests your endpoint against our counterparty, not against your specific partner's quirks, same structural limit as mendelson's server. You don't get counterparty side logs the way you do with your own OpenAS2 rig. The free tier covers the core test; higher volume and scheduled monitoring are paid. And it's hosted, so if your policy forbids external test traffic to your AS2 endpoint, option 2 is your route.

Pick it when you want an answer in minutes rather than an afternoon, you need a report a non expert (or a skeptical partner) can read, or you're testing under deadline pressure before a go-live.

What each option actually validates

All three prove the fundamentals if the exchange succeeds: your endpoint is reachable, encryption and signing work, and an MDN comes back. The difference is what happens when something is wrong, and how explicit the answer is.

TLS: mendelson and OpenAS2 exercise the handshake and fail opaquely if it breaks. AS2 Certify reports protocol version, cipher, and certificate validity as distinct findings.
Certificates: with mendelson and OpenAS2, a bad cert surfaces as a failed exchange you then diagnose. AS2 Certify checks expiry, chain completeness, and role assignment explicitly, before they cause a cryptic failure.
Encryption and signing: all three validate these by performing them. Only the graded report names the algorithm mismatch outright.
MDN: all three complete the round trip. mendelson and OpenAS2 hand you the MDN to verify; AS2 Certify verifies the signature and disposition for you.

When to pick which

Use mendelson's test server when you want a free, established, independent counterparty and you're fluent enough in AS2 logs to be your own analyst.

Run your own OpenAS2 instance when you need repeatable simulation of specific partner configs, visibility into both sides of the exchange, or fully in network testing, and the setup days are worth it for how often you'll reuse the rig.

Use AS2 Certify when you need a clear answer fast: pre go-live verification, post cert renewal checks, or producing evidence in a stalled partner debugging cycle.

They also combine well. Plenty of teams keep an OpenAS2 rig for deep simulation and use an automated test for the quick "is it still working" check after every change.

For the broader question of what a complete AS2 test needs to cover regardless of tooling, see our guide to testing an AS2 connection. And if you got here because a partner's requirements mention Drummond certification, that's a different thing entirely from connection testing; we untangle the two in AS2 Certification vs AS2 Connection Testing.

Whichever route you take, test before the go-live, not during it. Run the free 8-check test and know where you stand in 60 seconds.