add partner icon

Trading Partner Settings

Version: latest

Advanced Options

If you are simply following along the quick-start guide, you could skip these options. However if your partner has provided a detailed AS2 profile (configuration of expected format for sent/received messages), consider adjusting these settings as well.
Partner Configuration: Advanced Options

HTTPS Certificate

Although this is a relatively advanced configuration, it appears under partner URL settings - because it is important for establishing basic connectivity.

If your partner URL is HTTPS/SSL/TLS (starts with https://), and the partner’s endpoint (server) does not have a trusted TLS/HTTPS certificate, you may want to import that certificate, or one of its issuer certificates, under this option.

  • Turn on the Upload New switch to upload the TLS certificate received from your partner.

  • If you wish to assign an already uploaded TLS certificate, turn off the Upload New switch and select the certificate from the drop-down.

Encrypt Messages

Enable this when you wish to send encrypted messages to your partner (or your partner requests you to do so).

In most cases, encryption must be enabled - even if your partner did not request it explicitly.

AS2 Gateway will use the Encryption Certificate that you provided, earlier in the partner configuration, to encrypt outgoing files/payloads before sending them to your partner’s URL.

Encryption Certificate usually contains the public key of your partner. Once you encrypt your message with it and send it to them, they will use their corresponding private key to decrypt the received data. The secrecy of the private key ensures that only your partner can decrypt and make sense of your transmission. This covers the confidentiality aspect of AS2 security.

Encryption Algorithm

Choose an algorithm for message encryption.

The following encryption algorithms are currently supported in AS2 Gateway:

  • Triple DES (168-bit): DES_EDE3_CBC

  • AES (128-bit): AES128_CBC

  • AES (192-bit): AES192_CBC

  • AES (256-bit): AES256_CBC

  • Camellia (128-bit): CAMELLIA128_CBC

  • Camellia (192-bit): CAMELLIA192_CBC

  • Camellia (256-bit): CAMELLIA256_CBC

  • CAST5/CAST-128 (128-bit): CAST5_CBC

  • RC2/ARC2 (40-bit): RC2_CBC

  • SEED (128-bit): SEED_CBC

It is recommended to choose a strong algorithm (e.g. AES256_CBC) unless your partner has requested a specific algorithm.

Sign Messages

Enable this when you wish to include a digital signature when sending messages to your partner (or your partner requests you to do so).

In most cases, signing must be enabled - even if your partner did not request it explicitly.

AS2 Gateway will use the private key of your trading station to sign outgoing payloads before sending them to your partner.

When you shared your station’s partner configuration with your partner, they would have received the public certificate of your station. Using this, they can verify the signature generated during sending of the message, and ensure that:

  • it was you who actually sent the message (because the private key that signed the message is held only by you), and

  • the content was not tampered with, during transmission (because the signature contains a hash calculated over the original message content, which the recipient partner can compare with another has calculated on the actual received content).

This covers the authenticity, integrity and non-repudiation aspects of AS2 security.

Sign Digest Algorithm

Choose the hashing algorithm that would calculate a hash (digest) over the message content, when signing an outgoing an AS2 message or response MDN/receipt.

The following signing (digest) algorithms are currently supported in AS2 Gateway:

  • SHA1

  • MD5

  • MD2

  • SHA224

  • SHA256

  • SHA384

  • SHA512

Each algorithm may have slightly varying names, across the application; e.g. SHA256 may appear as SHA-256, sha256 and sha-256.

It is recommended to choose a "strong" algorithm that generates a longer hash (e.g. SHA-384 or SHA-256), unless your partner has requested a specific algorithm.

Use Different Certificate as Sign Certificate

Although this is a relatively advanced option, it currently appears under the encryption/sign certificates section itself.

If your partner has provided a "signature" or "verification" certificate, you can configure it here. This certificate will be used to verify the digital signatures of messages or MDNs (receipts) that your partner will send to you. Hence, unlike the encryption certificate that is used for outgoing messages, this will be used on incoming messages.

In most cases, partners use the same keypair for decrypting incoming traffic and signing outgoing traffic; hence, unless your partner has explicitly instructed you to use a different, specific certificate for signing, you would keep this option disabled.

Do not confuse this with the HTTPS/SSL/TLS certificate; if your partner has a HTTPS URL and has sent you only one additional certificate (in addition to the "partner" or "encryption" certificate), it is probably the TLS certificate of their HTTPS endpoint - unless it is explicitly marked as a signature certificate.

Compress Messages

Enable this when you wish to compress your files/content before sending them to your partner (or your partner requests you to do so). This can potentially save bandwidth and speed up transmission.

Compression Stage

You can choose to run the compression:

  • Before signing and/or encryption, i.e. on the original set of files that you included in the message; in this case, the partner would need to first decrypt/verify the payload, and then decompress it

  • After signing and/or encryption, i.e. compression would be the last (outermost) action or "layer" on the payload; in this case, the partner would need to first decompress the payload, and then decrypt/verify the content

Request MDN

Enable this when you want your partner to send back a MDN (acknowledgement, receipt) for each message that you send them.

An MDN ensures that your partner received your message, and acknowledges that they managed to successfully verify and retrieve the content (or, notifies that there was an error when trying to do so - via an error MDN). This covers the non-repudiation aspect of AS2 security. Once the MDN is received, you should be able to see its status (success: green, error: red, etc.) against the message, on your outbox.

Request Asynchronous MDN

An AS2 system can send MDNs in one of two ways:

  • synchronous: the MDN will be sent back on the same connection (HTTP/S channel) established for the original AS2 message, as the HTTP response to the original HTTP request that contained the AS2 message

  • asynchronous: the original AS2 message connection would be closed gracefully (e.g. with a HTTP 200 (OK) or 202 (Accepted) response), and the recipient (partner) will later send the MDN back to the sender (station) as a new HTTP request (on a new connection).

By enabling the Request Asynchronous MDN option, you request your partner to use the second approach. In this case, AS2 Gateway will inform the partner system where (the URL/endpoint) to send the asynchronous MDN, by including an additional Receipt-Delivery-Option HTTP header on each AS2 message. This URL is usually (or the variant); HTTPS is not supported.

Request Digitally Signed MDN

Similar to signing outgoing messages, you can request your partner to sign the MDNs that they send back to you.

Just as described before, this ensures that the MDNs are originated from your partner (private-key signature) and they have not been tampered with (signed content hash).

Request MDN over HTTPS

As described in the protocol overview, when requesting an async MDN, the sender has to specify the "callback" URL to which the receiver should send back the MDN. In AS2 Gateway this is a HTTP URL (http:// over port 8280) by default; however if your partner’s system can only talk HTTPS (e.g. due to firewall policies/restrictions), you can turn on this option to present a HTTPS callback URL instead (https:// on the standard port 443).


If you notice that your outbox AS2 messages are stuck in "MDN pending" status for prolonged amounts of time, your partner’s AS2 system may not be supporting the current MDN configuration. Contact your partner to learn the supported MDN scheme (e.g. synchronous, not signed), and update the AS2 Gateway MDN configuration accordingly.

Partner Type

This helps you to maintain separate configurations for your (and your partners') test and production connections while using the same AS2 identifier; however, it should be used with caution, and proper understanding by both parties.

Basically you define two partner entries with each type, using the same AS2 identifier (and identical or different configurations, as recommended/requested by your remote trading partner). Afterwards, your partner can simply send messages to the respective endpoint (test URL vs production URL) to differentiate the environment, using the same AS2 ID, and keeping all other configurations unchanged on their side.

Generally in most cases, you can stick to Production type; otherwise you can first set up Test communications, and later - when you start exchanging production messages:

  • change the partner type to Production, and

  • instruct the partner to point the URL to AS2 Gateway production endpoint, keeping all other configurations unchanged.

You would need two partners of each type, only if you wish to continue to receive both test and production messages.

Check out our Partner Types reference for more details.


Specify a description of your trading partner; mainly just for identification purposes within your AS2 Gateway account.

Message Subject

Specify a default message subject, which will be used if a subject is not specified when sending a message (e.g. via SFTP outbox uploads, or API-based submissions without a subject query parameter)

Custom Headers

Some trading partners require you to send additional HTTP headers along with a standard AS2 message (e.g. for authentication or routing purposes). You can use this option to add one or more such headers as key-value pairs.

For example, to add the two headers

X-Cyclone-Routing-Key: ACME_PROD
Authorization: Basic abcdefgh1234
  1. Click +, to add a new key-value pair.

  2. Enter X-Cyclone-Routing-Key (excluding the colon and space, `: `) on the Header Key field.

  3. Enter ACME_PROD on the Header Value field.

  4. Repeat above steps for the second header: key Authorization, value Basic abcdefgh1234.

To remove an already defined header, click the dustbin-icon button against that row.

  • Header keys cannot be left empty. If you submit an entry with an empty header key, it will be ignored.

  • Headers will be included in the AS2 message (HTTP request) in the order they are defined.

If your partner provides you with a username/password pair to use as basic authentication, you need to derive the header value as:

"Basic "base_64_encode(username":"password)

E.g. for username foo and password bar, the header would be:

Header Key:

Header Value:
Basic Zm9vOmJhcg==

You can also use a secure utility, such as this page, to generate the header.

Once added, these headers will be included in every AS2 message that you send to this partner. If you want to:

  • apply them to only some of the AS2 messages, based on some condition, or

  • determine/change the value of a certain header, based on some condition/parameter,

contact AS2 Gateway Team for more information.

Transmission Timeout

After sending an AS2 message, AS2 Gateway waits for a finite amount of time to receive the network-level (HTTP) response for the transmission. If the response is not received within this time, the transmission is considered as a failure.

If your partner’s AS2 system generally tends to take a long time to respond, you may start getting many such "connection timed out" errors. In such cases, you can try increasing this Transmission Timeout value to tolerate such large delays, instead of failing at the default 60-second (1-minute) timeout.

The transmission timeout does not apply to asynchronous MDNs; if you send a message requesting an asynchronous MDN, and the partner sends the HTTP-level response (network acknowledgement) within the time-out period, all would be fine - regardless of how long the partner may take to send the final MDN. Even if the MDN gets delayed by several hours, AS2 Gateway will continue retaining the message in "MDN pending" status until it is received.

Custom Integration Flows

These are additional features that you can enable, based on the nature of the partner or of the transmitted files/messages; for example,

  • FDA: when this integration is enabled on a FDA partner (e.g. ZZFDA), submissions you make will be automatically tracked and tagged using correlation information available in received messages/responses (e.g. FDA Core-ID). Refer to the FDA communication reference for more details.

In this topic
In this topic