Skip to main content
Alongside the per-merchant payment providers, MyCryptoServer has a set of platform integrations: deployment-wide infrastructure the operator configures once, not per merchant. They power blockchain RPC + webhooks, transactional email, key custody, gas estimation, and crypto pricing. All of them live in the same place — Dashboard → Integrations — and share the same contract:
  • Platform scope. Configured once for the whole deployment (unlike payment providers, which are per-merchant).
  • Database-backed. Credentials are stored encrypted in the database, not in environment variables. The DB is the single source of truth — there is no env fallback.
  • Public vs private fields. Non-secret values (a from-address, a region) are stored in plaintext; secrets (API keys, access keys) are stored encrypted and are never returned to the browser — the UI only shows whether each is set.
  • Graceful fallback. Each integration degrades safely when not configured (details per integration below), so a fresh deployment still runs.
These are all optional. A new deployment works without them — payments fall back to polling, emails print to the server log, seeds use the local passphrase, and gas uses a static estimate. Enable each one to upgrade that behavior.

​
Enabling an integration

1

Open the tile

Go to Dashboard → Integrations and open the integration’s tile.
2

Fill in the fields and enable

Enter the public and private fields (listed per integration below) and toggle the integration on. Private fields are write-only — leave one blank to keep its existing value.
3

Save

Saving persists the config (secrets encrypted) and invalidates the in-process config cache, so the new values take effect within ~a minute across warm instances.

​
Alchemy

Blockchain RPC and real-time payment webhooks. When enabled, payment detection is push-based (Alchemy Notify) instead of polling, so payments confirm near-instantly. Webhook subscriptions are managed automatically and lazily — there’s no separate provisioning step. If Alchemy isn’t configured, the server falls back to polling for on-chain payments. See Self-Hosting → Alchemy for the deeper setup and webhook details.

​
Resend

Transactional email. Powers sign-in 2FA codes, team invites, password resets, checkout emails, and operational alerts (failed sweeps, low gas, watcher failures). Operational alerts are sent to each merchant’s own address. If Resend isn’t configured, these messages are printed to the server logs instead of being emailed — convenient for local development. See Self-Hosting → Authentication for how sign-in codes use this.

​
AWS KMS

Envelope encryption for merchant wallet seeds. When enabled, new mnemonics are encrypted with a KMS-wrapped data key (KMS-managed DEK + local AES-256-GCM) instead of the local MASTER_PASSPHRASE scrypt path — so a database breach alone cannot expose private keys. Fallback is non-destructive: seeds created before enabling KMS continue to decrypt via the legacy passphrase path, and only new seeds use KMS once all four fields are present and the integration is enabled. See Self-Hosting → Wallet for the key-custody model.

​
Blocknative

Real-time EIP-1559 gas fee estimates for EVM sweeps. When enabled, sweep transactions use Blocknative’s 99% confidence fee tier instead of a static 15% buffer on the RPC gas price — reducing overpayment in calm periods and failed sweeps during gas spikes. Fallback chain if Blocknative is not configured or errors: viem’s estimateFeesPerGas (EIP-1559) → legacy getGasPrice. See Concepts → Sweep for how fees feed into sweeping.

​
Google Analytics

GA4 tracking on the hosted checkout pages (and only there — the merchant dashboard is never tracked). When enabled, checkout loads gtag.js with your Measurement ID and reports:
  • begin_checkout when a checkout page loads, with value and currency from the session’s fiat amount.
  • purchase once the payment confirms on-chain (fired exactly once per session), with transaction_id (the session id), value, and currency — so payments appear as conversions in GA4.
Can be enabled alongside Google Tag Manager; each loads independently.

​
Google Tag Manager

Loads your GTM container on the hosted checkout pages (and only there). Checkout pushes the same begin_checkout and purchase events described above into the dataLayer, so your GTM triggers can forward them to GA4, ads pixels, or anything else you manage in Tag Manager. Both IDs are public by nature (they ship in page source on any site using them), so they’re stored as public fields.

​
Meta Pixel (Facebook)

Meta (Facebook) Pixel tracking on the hosted checkout pages (and only there). When enabled, checkout loads fbevents.js with your Pixel ID and reports the standard events Meta’s ad tools understand:
  • PageView and InitiateCheckout when a checkout page loads (the latter with value and currency from the session’s fiat amount).
  • Purchase once the payment confirms on-chain (fired exactly once per session), with value and currency — so checkouts count as conversions for Facebook/Instagram ad campaigns.
Like the Google integrations above, the Pixel ID is public by nature and can be enabled alongside them; each snippet loads independently.

​
Pricing sources

To convert a checkout’s fiat amount into crypto, the platform uses a pricing source. Two are dedicated pricing integrations — CoinGecko and CoinMarketCap — and Alchemy can double as one (see above). They share the same priority-with-fallback model: the highest-priority source is tried first, the next covers an outage, and a short-lived cache backs them all up. Stablecoins (USDC/USDT/DAI) are always priced 1:1 and need no source; any volatile coin (ETH, BTC, …) needs at least one source enabled. Full setup, free-tier notes, and direct links to get each API key are on the dedicated Pricing page.