Connecting to Orderful via AS2

This guide walks through setting up a direct AS2 connection with Orderful, in the order that avoids the most common delays. It is written for the technical team on the trading partner side (EDI developers, AS2 administrators), whether or not you are an Orderful user.

If you only need Orderful's connection values, see Orderful AS2 information. If you already have a connection and it's failing, jump to Troubleshooting by symptom below or the full error catalog in AS2 Troubleshooting.

Orderful's AS2 details at a glance

Setting	Value
AS2 ID	`ORDERFULAS2` (US) or `ORDERFULAS2EU` (EU)
AS2 URL	`https://as2.orderful.com` (US) or `https://as2-eu.orderful.com` (EU)
Port	443 (HTTPS, recommended). HTTP on port 80 is available but discouraged.
Certificate	Download ORDERFULAS2.cer (US). One certificate for both signing and encryption.
MDN	Synchronous only, signed. Asynchronous MDN requests are rejected.
Encryption	Required. 3DES, AES128, AES192, or AES256. Orderful sends using 3DES by default.
Signing	SHA-256 recommended. SHA-1, SHA-384, and SHA-512 also supported.
Compression	Not supported — send uncompressed.
Max message size	50 MB on the wire.
Environments	One endpoint serves both test and production. Routing is by AS2 ID pair, not by URL.

📘
Some connections use a channel-specific Orderful AS2 ID instead of ORDERFULAS2 (for example, an ID like ORDERFUL49C59373). Always use the exact AS2 ID provided for your connection — for each environment, if your test and production connections were given different IDs.

Step 1 — Allowlist Orderful's IP addresses in every environment

Orderful sends AS2 traffic from a fixed set of egress IP addresses. If your AS2 server sits behind a firewall or IP allowlist, add all of the addresses listed in IP Whitelisting before running any connectivity test.

❗️
Apply the allowlist to every AS2 profile and firewall zone you operate — test/QA and production. The single most common cause of a stalled AS2 setup is an allowlist applied to one environment while testing targets another. If your organization's test and production AS2 endpoints are managed by different internal teams, confirm the change with both.

How to tell whether the firewall is the problem:

Orderful's sends time out with no response at all (no HTTP status, no MDN) → traffic is not reaching your AS2 server. This is almost always an IP allowlist or firewall issue.
Orderful's sends get an HTTP error response (for example, a 500) → traffic is reaching your server, and the problem has moved to profile configuration (Step 3). An error response after a history of timeouts is progress, not regression.

Step 2 — Exchange connection details

Orderful needs the following from you. If your test and production AS2 profiles differ, provide a set of values for each environment:

Your AS2 ID — exactly as your server presents it. AS2 IDs are matched case-sensitively.
Your AS2 URL and port (for example, https://as2.yourcompany.com:5080/as2)
Your public certificate(s) in .cer, .crt, or .pem X.509 format — one certificate, or separate signing and encryption certificates if you use dual certificates
Preferred algorithms — encryption (3DES or AES) and signing digest (SHA-256 recommended)
Static IP addresses your server sends from, if you want Orderful to expect them

In return, configure Orderful's AS2 ID, URL, and certificate from the table above.

❗️
Orderful routes every inbound message by the exact, case-sensitive pair of AS2 IDs in the AS2-From and AS2-To headers. A single wrong character in either ID breaks both directions: your sends to Orderful are rejected with the MDN failure missing-comm-channel, and Orderful's sends to you fail because your server doesn't recognize the sender. Confirm both IDs character-for-character before testing.

Step 3 — Configure your AS2 profile

Setting	Required value
Partner AS2 ID (Orderful)	`ORDERFULAS2` — or the channel-specific ID Orderful provided
Partner URL	`https://as2.orderful.com`, port `443`
Partner certificate	Orderful's `.cer` — used to encrypt messages to Orderful and to verify Orderful's signatures and MDNs
MDN mode	Synchronous, signed receipt requested. Do not configure an asynchronous MDN return URL (`Receipt-Delivery-Option`) — Orderful rejects the message immediately.
Message security	Sign and encrypt every message
Encryption algorithm	3DES or AES128/AES192/AES256
Signing digest	SHA-256 recommended
Compression	Off

🚧
Orderful returns HTTP 200 for both success and failure — the actual result is the MDN disposition in the response body. Configure your AS2 software to evaluate the disposition, not just the HTTP status code. The only non-200 response you should ever see is a 503 during an Orderful maintenance window (safe to retry later).

Step 4 — Run connectivity tests in both directions, in both environments

A connection is not verified until all four of these pass:

	Test environment	Production environment
Orderful → You	Orderful sends a test file; your server returns a signed synchronous MDN	Same — don't skip it
You → Orderful	Send a test document; confirm the MDN disposition is `processed`	Same — don't skip it

Notes:

Orderful typically uses an 864 (Text Message) as the connectivity test document. It has the highest pass probability because some AS2 servers validate the ISA sender/receiver IDs against known partnerships before accepting a file.
A successful send to Orderful returns a signed MDN with disposition automatic-action/MDN-sent-automatically; processed.
Test and production often live on separate profiles or servers on your side. It is common for the test connection to pass while production keeps failing simply because the production profile was never completed. Verify each environment independently.

Troubleshooting by symptom

For the complete error catalog (every HTTP code and MDN disposition), see AS2 Troubleshooting. The table below starts from what you observe:

Symptom	Likely cause	Fix
Orderful's send times out, no HTTP response	Firewall / IP allowlist blocking Orderful's egress IPs — often applied to one environment but not the other	Allowlist all Orderful IPs in every environment, then re-test
Orderful's send reaches you but gets an HTTP 500	Your AS2 profile is incomplete or misconfigured — wrong expected sender ID, missing certificate, or profile not activated	Verify the profile expects `AS2-From: ORDERFULAS2` (exact case), has Orderful's certificate loaded, and is enabled
MDN failure `missing-comm-channel`	The AS2 ID pair doesn't match a configured Orderful channel	Confirm both AS2 IDs character-for-character; IDs are case-sensitive
MDN error `integrity-check-failed` ("the signature of the sender couldn't be verified")	Certificate mismatch — you rotated certificates, or signed with a certificate Orderful doesn't have	Send Orderful your current public certificate; if you use dual certificates, identify which is signing vs. encryption
MDN error `decryption-failed`	Message encrypted with the wrong certificate (must be Orderful's), unsupported algorithm, or not encrypted at all	Encrypt with Orderful's current `.cer` using 3DES or AES
MDN failure `asynchronous-mdn-unsupported`	Your profile requests an asynchronous MDN	Switch MDN mode to synchronous
Orderful reports "No MDN has been received" on sends to you	Your server accepted the file but didn't return a synchronous MDN on the same connection	Configure your server to return the MDN synchronously; check your AS2 logs for MDN generation errors
MDN failure `undergoing-maintenance` or HTTP `503`	Orderful maintenance window	Retry later — resending the same message is safe
Failure mentioning the content size limit	Message over 50 MB on the wire	Split the interchange into smaller files
Test works, production fails (or vice versa)	Only one environment was fully set up	Repeat the allowlist, profile configuration, and connectivity tests for each environment

Pre-flight checklist

Before scheduling a go-live or escalating a connection issue, confirm every item:

If a connection issue persists after this checklist, contact [email protected] with: the AS2 IDs on both sides, the environment (test or production), the timestamp of a failed attempt, and the exact error or MDN disposition observed.