Skip to main content

Documentation Index

Fetch the complete documentation index at: https://developers.ingopayments.com/llms.txt

Use this file to discover all available pages before exploring further.

Both Embedded Account Capture and Notify require custom domain configuration before going live. These are white-labeled deployments — the URLs your recipients see correspond to your domain, not Ingo’s. Your Integration Manager coordinates the domain naming during onboarding and confirms all required values. This page documents what your DNS and IT teams need to configure.
All CNAME records and DNS values shown below use placeholder names. Your Integration Manager provides the exact values — including client-specific CNAME targets and email authentication keys — during the implementation phase.

​
Embedded Account Capture

The Embedded Account Capture iFrame requires one custom domain per environment. The domain must correspond to the root domain of the application embedding the iFrame — this is used as a security control, as Ingo whitelists authorized application domains on the backend.

​
Domain architecture

A single iFrame instance operates under a single participant_id. If your application uses multiple domain naming conventions (e.g., different subdomains per brand or environment), each requires a separate iFrame configuration, a separate participant_id, and a separate set of HMAC credentials. Work with your Integration Manager early to map your application domain structure to the required iFrame and credential topology.

​
CNAME records

Create the following DNS CNAME records in your DNS provider: Sandbox 
webplugin-uat.{your-domain}.com  CNAME  {your-client-name}.webplugin.uat.ingo.money
Production 
webplugin.{your-domain}.com  CNAME  {your-client-name}.webplugin.ingo.money
Replace {your-domain} with your organization’s root domain and {your-client-name} with the identifier provided by your Integration Manager.

​
Notify — Classic & Managed Parties

Notify is a fully hosted solution and requires two custom domains: one for the visible Digital Payment Center URL presented to recipients, and one for the embedded iFrame within that experience. Both must be configured per environment.

​
CNAME records

Create the following DNS CNAME records in your DNS provider: Production 
digitalpay.{your-domain}.com  CNAME  {your-domain}.digitalpay.ingo.money
webplugin.{your-domain}.com   CNAME  {your-domain}.webplugin.ingo.money
If you support multiple brands requiring distinct Digital Payment Center experiences, you will need two production URLs per branded experience. Your Integration Manager will assist in defining the naming convention for each.

​
Email DNS records

Notify uses your domain to send email notifications to recipients — this preserves your domain reputation and improves deliverability with inbox providers. Four DNS records are required. Your Integration Manager provides the exact values for your organization during onboarding. The record types and their structure are: SPF record — authorizes Ingo’s sending infrastructure to deliver email on behalf of your domain: 
{your-domain}.com.  TXT  "v=spf1 ip4:{ingo-smtp-ip} -all"
DKIM record — cryptographic signature proving email authenticity: 
spop1024._domainkey.{your-domain}.com  IN TXT  "k=rsa; p={your-dkim-public-key}"
Yahoo Verification Key — required for deliverability to Yahoo and AOL inboxes: 
{your-domain}.com.  TXT  "yahoo-verification-key={your-yahoo-verification-key}"
DMARC record — instructs receiving mail servers how to handle unauthenticated email from your domain: 
_dmarc.{your-domain}.com  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@{your-domain}.com"
The DMARC policy (p=none, p=quarantine, or p=reject) should align with your organization’s existing email security posture. Your Integration Manager can advise on a policy compatible with Ingo’s sending infrastructure if you do not have an existing DMARC policy in place.

​
SMS delivery options

Notify can deliver recipient notifications via SMS through two supported approaches — you choose based on your program’s infrastructure and brand requirements: Ingo-managed SMS — Ingo sends SMS notifications directly to recipients on your behalf. Prior to activation, Ingo must obtain documented recipient consent. Ingo provides a consent form for this purpose, though it identifies Ingo as the notification sender rather than your brand. This approach is well-suited for programs where transparency about Ingo’s role as a service provider is acceptable. Client-managed SMS — Many clients prefer to send SMS notifications through their own SMS platform (e.g., Twilio, Bandwidth, or a similar provider) for full brand control. Recipients see only your brand in the notification. Your system delivers the notification and directs recipients to the Ingo-hosted disbursement URL. This approach gives you complete control over the recipient communication experience and works well for programs with existing SMS infrastructure. Both approaches are supported and can coexist within a single program. Contact your Integration Manager to confirm which configuration is appropriate for your use case.

​
What to prepare

Before your kickoff call, confirm the following with your IT and DNS teams:
  • The root domain(s) of your application(s) embedding the iFrame
  • Whether you support multiple domain naming conventions requiring multiple iFrame instances
  • Whether you have an existing DMARC policy in place
  • Whether you have an existing SMS platform you intend to integrate, or plan to use Ingo-managed SMS
Your Integration Manager will provide exact CNAME targets, DKIM keys, Yahoo verification keys, and authorized domain values once your program configuration is confirmed.