Connections

MoneyHash (MH) is a network built on top of different integrations, with various methods and services. These services and methods vary based on the service provider, type of service, and other factors. All of this is encapsulated under one concept: a connection.

Understanding Connections

A connection, as the name suggests, is a link between MoneyHash and a service provider. This structure follows a hierarchical organization:

• At the top level is the connection itself (e.g., Stripe, PayPal)
• Within each connection, you'll find services that you can enable (e.g., Payin, Payout)
• Within each service, you'll find methods you can use (e.g., Card Payin, Bank Transfer)

For example: MoneyHash has a connection with Stripe, a payment service provider. In this connection, you can enable your Payin service, and within that service, you can enable your Card Payin Method.

Multiple Connection Instances

You can have multiple instances of the same connection—such as Stripe—each with its own configuration:

• Connected to different accounts (e.g., different Stripe accounts for different business units)
• Connected to the same account but with different credentials
• Configured with different settings based on your business needs

This flexibility allows you to tailor your payment infrastructure to suit various business requirements across different markets, products, or customer segments.

PayIn Method Integration Types

MoneyHash offers multiple ways to integrate payment methods into your system. Each integration type determines how MoneyHash interacts with payment providers and affects your payment flow.

Why Integration Types Matter

Your choice of integration impacts user experience, security, and available features. Different types offer varying capabilities like card tokenization, provider fallback options, and checkout flow control. The table below compares these integration types across key features. MoneyHash recommends Server-to-Server integration whenever possible as it provides the most comprehensive feature set, including card tokenization, provider fallback support, advanced SDK capabilities, and native experience control.

Apple Pay & other Native Pay Integration Types

1. Provider Hosted

What It Is:

• The Apple Pay interface is hosted entirely by the payment provider (via an iframe or redirect)

Pros:

• Minimal Setup: The provider handles most of the payment logic, reducing your development overhead
• Less Dev Work: No need to manage Apple Pay certificates or deep integrations
• Provider Updates: Changes in Apple Pay flows are handled by the provider, so you get them automatically

Cons:

• Extra Steps: Typically requires two clicks—one on the MoneyHash flow, then another on the provider's page
• Limited Branding: The provider dictates styling and UI, so you have little design control
• Less Seamless: The buyer either leaves your site entirely or interacts with an embedded iframe, which can feel disjointed

2. MoneyHash Hosted

What It Is:

• MoneyHash hosts the Apple Pay interface in an iframe or redirect, triggered from your site in a single click

Pros:

• One-Click Flow: Only one action is needed from the user to open the payment sheet
• Moderate Customization: Slightly more branding control compared to provider-hosted solutions
• Easier Integration: MoneyHash handles the majority of Apple Pay specifics (e.g., certificates, setup)

Cons:

• Not Fully Native: The payment sheet still appears in an external frame or redirected page
• Brand Constraints: MoneyHash environment partially governs the user interface and styling
• Some Setup Required: You need to configure this in MoneyHash's dashboard, though it's typically less complex than merchant-hosted

3. Merchant Hosted

What It Is:

• Your own site or app directly embeds the Apple Pay button, launching the payment sheet in a fully native experience with one click

Pros:

• Best User Experience: The payment sheet pops up immediately, staying within your own flow; typically leads to higher conversion
• Full Branding Control: You decide how to place and style the Apple Pay button (within Apple guidelines)
• Single-Click Checkout: Minimizes friction for the buyer, who can quickly authorize payment

Cons:

• More Implementation: You're responsible for Apple domain verification and following their technical requirements, Moneyhash has an automated guide here, that will help you through this.
• Technical Overhead: Ongoing updates and maintenance of the payment button code fall on you, rather than on MoneyHash or the provider
• Brand Rules: You must comply strictly with Apple's design and usage guidelines for the payment button

Connection Environments

Connecting in Test Mode

MoneyHash provides a dedicated Test Mode that allows you to set up and experiment with new connections without requiring a registered account on the service provider's system. In this mode, a MoneyHash simulator intercepts all requests, preventing them from reaching any real external provider. This way, you can safely explore functionality, confirm workflows, and validate your integration logic—all without the need for real credentials.

To learn more about how MoneyHash separates test and live environments, review our Environments concept page, which compares Test Mode and Live Mode in detail.

Moving to Live Mode

Once you're satisfied with your initial testing, you can switch your MoneyHash mode to Live Mode. Unlike Test Mode, Live Mode requires each connection to link to an actual service provider's account. This means:

• You must register with the provider and have valid credentials (API keys, tokens, etc.)
• You'll need to configure the connection settings (e.g., authentication parameters, service‐specific options)
• Detailed instructions for acquiring and entering these credentials are found on each connection's dedicated dashboard page in MoneyHash

For a comprehensive, step‐by‐step tutorial on setting up new connections, refer to our Connect Connections page. There, you'll find screenshots, troubleshooting tips, and other practical advice to ensure your integrations are configured correctly.

Once you’re in Live Mode, you proceed through two possible sub‐phases, depending on the provider's capabilities:

Connection's Sandbox

Many payment providers offer a sandbox or staging environment of their own, which allows you to test with real credentials but without involving actual money. In this stage:

• You provide the genuine credentials needed by the provider
• All requests go to the provider's sandbox endpoints
• MoneyHash still mediates communication, forwarding your calls and returning the provider's sandbox responses
• Transactions do not cause actual financial movement, so you can safely test end‐to‐end flows like authorization, capture, and refunds

Live Payment Mode

Once you're confident everything works correctly in the provider's sandbox—or if the provider doesn't offer a sandbox—your last step is to enable full production payments, by using live payment credentials provided by your payment provider
In this stage:

• All transactions use genuine credentials and real endpoints
• Financial operations result in actual money movement
• Regulatory requirements, compliance checks, and production‐grade security measures fully apply
• Real transaction IDs and account identifiers are used, and the funds are truly settled or disbursed as appropriate