> ## Documentation Index
> Fetch the complete documentation index at: https://docs.m1amdocs.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Connectivity Best Practices

This topic contains Reseller (Service Provider) connectivity best practices recommendations.

## Connectivity

**Configuration Expectations**

All configuration expectations should be reviewed and agreed upon by both software architects and the DevOps team.

Configuration Expectations

The following two Reseller (Service Provider)-to-MarketONE connection methods can be used.

1. Public Interface. This is the recommended method.
2. [AWS Direct Connect](https://aws.amazon.com/directconnect/). This method a direct Layer 2 (L2) link to the customer site from AWS.

**Note:** The MarketONE ↔ Reseller (Service Provider) connectivity plan should be reviewed during the initial contact negotiations, and during the final contract sign-off. Some of the solutions may require extra budgeting considerations.

## AWS Connectivity

**Note:** Please refer to [Building a Scalable and Secure Multi-VPC AWS Network Infrastructure](https://d1.awsstatic.com/whitepapers/building-a-scalable-and-secure-multi-vpc-aws-network-infrastructure.pdf) for AWS Connectivity best practices recommendations.

## BSS Idempotency

It is possible that a non-idempotent BSS (with the enterprise service bus (ESB) in front, and multiple legacy systems in the backend) might take a very long time to respond to a transaction. In this situation, if a Merchant submits a transaction, and is not notified in a reasonable amount of time that it has been successfully processed by the BSS, the Merchant might conclude that the transaction has failed. In response to this possibility, a Merchant might then retry the same transaction later, only to have the non-idempotent BSS return a duplicate transaction error.

To avoid this situation it is *strongly* recommended that the Reseller (Service Provider) BSS be idempotent. This way even if the BSS receives a transaction multiple times from a Merchant, it will always return the same outcome.

## Retry Mechanism

Requests that come into MarketONE are validated by an API key. Occasionally the validation of the key (as part of the SSL handshake) results in a timeout, thereby returning one of the following 5xx errors back to the client:

| Error | Description |
| - | - |
| `502` | This **Bad Gateway** error is usually due to improperly configured proxy servers. However, the problem may also arise when there is poor IP communication between backend computers, when the client's server is overloaded, or when a firewall is functioning improperly. |
| `503` | This **Service Unavailable** error occurs when the server is unable to handle requests due to a temporary overload or due to the server being temporarily closed for maintenance. The error indicates that the server will only temporarily be down. |
| `504` | This **Gateway Timeout** error occurs when a server somewhere along the chain does not receive a timely response from a server further up the chain. The problem is caused entirely by slow communication between upstream computers. |

**Note:** To overcome these occasional connection timeouts, MarketONE recommends that you implement a retry mechanism. Please refer to the AWS [Timeouts, Retries, and Backoff with Jitter](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/) page for further information.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.