kevin.s

Posted on Jul 23

Build a Crypto Payment Support Desk

#webdev #api #crypto #backend

Most developers think about crypto payments as a checkout problem.

Generate an invoice.
Show a payment page.
Wait for a webhook.
Mark the order as paid.

That is the clean version.

Real merchants do not live in the clean version.

They live in support tickets.

A customer says they paid, but the order is still pending.
A payment arrives after the invoice expires.
Someone sends the right amount on the wrong network.
A webhook fails.
A customer underpays.
A support agent cannot tell whether the issue is customer error, blockchain delay, invoice expiry, fulfillment failure, or an internal system bug.

This is where developers can build a real product.

A Crypto Payment Support Desk is a support and operations layer for merchants that accept crypto payments. It helps support teams search payments, inspect payment timelines, classify issues, explain statuses to customers, escalate real problems, and reduce the amount of manual investigation required for every crypto payment ticket.

In this article, I will use OxaPay as the example payment infrastructure because its documentation exposes the primitives needed to build this kind of product: invoice generation, payment status callbacks, HMAC-signed webhooks, payment information lookup, payment history, static addresses, SDKs, plugins, and automation integrations.

This is not a generic “add crypto payments to your app” article.

It is a blueprint for developers who want to build a support-facing product that merchants may actually pay for.

The business idea

The idea is simple:

Build a support desk that sits between a merchant's payment system, order system, and support team.

The merchant already accepts crypto payments.

The problem is that their support team cannot quickly answer payment-related questions.

Your product gives them one place to investigate cases like:

“The customer says they paid, but the order is unpaid.”
“The invoice expired, but a transaction later appeared.”
“The payment is underpaid.”
“The webhook was received, but fulfillment did not happen.”
“The support team needs a safe customer-facing status explanation.”
“Finance wants to know which payment issues are still unresolved.”

The product is not a payment gateway.

It is not a wallet.

It is not an exchange.

It is a payment support operations tool.

That distinction matters because merchants do not pay only for APIs. They pay for reduced confusion, fewer unresolved tickets, faster support handling, cleaner internal workflows, and better visibility into payment incidents.

Why this can be a real developer business

Support tooling becomes valuable when three things happen:

A workflow repeats often.
Manual investigation is slow.
Mistakes cost money, time, reputation, or customer trust.

Crypto payments create exactly that situation for many merchants.

A card payment support agent usually has a payment processor dashboard, a dispute dashboard, a refund panel, and clear payment states.

A crypto payment support agent may need to check:

the merchant order system,
the invoice status,
the payment amount,
the selected coin,
the selected network,
the invoice expiration time,
the payment status,
webhook delivery,
fulfillment status,
internal notes,
and sometimes payout or refund state.

Without a support desk, this becomes a Slack thread, a spreadsheet, a manual API check, or a developer interruption.

That is a product opportunity.

You are not selling “crypto payment integration.”

You are selling:

A way for merchants to handle crypto payment support without asking developers to debug every payment issue.

Who would use this service?

This product is most useful for merchants that already have enough payment volume to feel operational pain.

Good targets include:

digital product stores,
SaaS apps,
hosting providers,
VPN and proxy resellers,
online course platforms,
software license sellers,
Telegram or Discord paid communities,
agencies managing merchant clients,
marketplaces,
donation platforms,
affiliate platforms,
and any business with international crypto-paying customers.

The first buyer is usually not the CEO.

It may be:

a founder who still handles support manually,
a developer tired of payment debugging,
a support manager,
an operations manager,
or a finance/admin person who needs cleaner payment records.

The more support tickets a merchant receives, the easier this product is to justify.

The core merchant pain

The pain is not simply “we need to know if a payment was paid.”

The real pain is context.

A support agent needs to answer a customer quickly and safely.

That means the agent needs to know:

which order the payment belongs to,
whether the invoice is still active,
whether OxaPay has detected payment activity,
whether the customer paid fully,
whether the payment became paid, underpaid, expired, or another status,
whether the webhook was received,
whether the merchant system processed the webhook,
whether fulfillment happened,
whether the case needs finance or developer review,
and what message can be sent back to the customer.

A Crypto Payment Support Desk turns this into a structured workflow.

What you are building

At MVP level, you are building a web app with four main areas.

1. Payment search

Support agents can search by:

order ID,
invoice ID,
OxaPay track_id,
customer email,
amount,
coin,
network,
date range,
status,
or internal case ID.

2. Payment timeline

Each payment has a readable event timeline:

Invoice created
Customer selected currency
Payment activity detected
Webhook received
Payment status changed
Merchant order updated
Fulfillment attempted
Fulfillment completed or failed
Support case created
Support case resolved

3. Issue classification

The tool automatically classifies common cases:

paid but not fulfilled,
expired invoice,
underpaid invoice,
webhook not received,
webhook received but not processed,
duplicate callback,
unknown payment reference,
static address deposit needs review,
fulfillment failed,
possible customer mistake,
manual review required.

4. Support response assistant

The tool provides safe support templates.

For example:

We found your payment attempt, but the invoice has not reached the final paid status yet. We are monitoring the payment status and will update your order once it is confirmed.

Or:

Your invoice expired before full payment was received. Our support team is reviewing the case and will contact you with the next step.

This matters because support agents should not improvise payment explanations for every crypto issue.

Why OxaPay is useful for this kind of product

A support desk needs payment visibility. OxaPay exposes several useful primitives for that.

Generate Invoice

OxaPay's invoice endpoint lets a merchant create a new invoice and receive a payment URL. The request can include order-related metadata such as order_id, plus a callback_url for payment updates.

That means your app can link a merchant order to an OxaPay payment session from the beginning.

Payment Status Table

OxaPay documents payment statuses such as new, waiting, paying, paid, manual_accept, underpaid, refunding, refunded, and expired.

A support desk can map these technical statuses into agent-friendly explanations.

Webhook

OxaPay webhooks send payment status updates to the merchant's configured callback URL. The Python SDK documentation also notes HMAC validation using SHA-512 over the raw request body.

For a support desk, webhooks become the event stream.

Payment Information

OxaPay's Payment Information endpoint retrieves details for a specific payment using its track_id.

This is useful when a support agent opens a case and needs the latest payment state.

Payment History

OxaPay's Payment History endpoint returns payment records associated with the merchant API key and supports filtering, time ranges, status filters, and pagination.

This is useful for backfill jobs, reporting, and detecting missed webhook events.

Static Address

OxaPay can generate a static address linked to a track_id, and callbacks can be configured for payments made to that address.

Static addresses are useful for deposits, top-ups, recurring deposit flows, and customer-specific wallet addresses, but they create additional support needs because payments may not map to a one-time invoice in the same way.

SDKs and automation integrations

OxaPay provides SDKs for PHP, Python, and Laravel. Its Make integration exposes modules such as invoice generation, payment information, payment search, static address generation, payout generation, and webhook watchers.

This gives developers multiple build paths:

full custom SaaS,
agency tool,
internal support dashboard,
low-code support workflow,
or hybrid productized service.

The main architecture

A practical Crypto Payment Support Desk needs to combine webhook data, order data, payment history, and support case data.

Customer checkout
      ↓
Merchant app creates OxaPay invoice
      ↓
OxaPay payment session
      ↓
Customer pays or abandons invoice
      ↓
OxaPay webhook callback
      ↓
Webhook ingestion service
      ↓
Payment event store
      ↓
Reconciliation and classification engine
      ↓
Support desk dashboard
      ↓
Agent response, escalation, or resolution

A production system should not depend only on webhooks.

It should also run scheduled sync jobs using Payment History or Payment Information, because support tools need recovery paths when callbacks are missed, delayed, rejected, or not processed by the merchant system.

The key design principle: support needs timelines, not just statuses

A payment status alone is not enough.

A support agent does not only need to know:

status = paid

They need to know:

Invoice created at 10:01
Customer selected USDT/TRC20 at 10:03
Payment detected at 10:07
Webhook received at 10:08
Merchant fulfillment failed at 10:08
Support case opened at 10:14

This timeline tells the real story.

The payment may be fine.

The fulfillment may be broken.

Or the customer may have paid late.

Or the webhook may have been rejected.

A support desk should show the whole operational history.

Data model

Here is a practical starting schema.

You can adapt it for PostgreSQL, MySQL, SQLite, or your SaaS framework of choice.

CREATE TABLE merchants (
  id UUID PRIMARY KEY,
  name TEXT NOT NULL,
  oxapay_merchant_key_encrypted TEXT NOT NULL,
  webhook_secret_hint TEXT,
  created_at TIMESTAMP NOT NULL DEFAULT now()
);

CREATE TABLE customers (
  id UUID PRIMARY KEY,
  merchant_id UUID NOT NULL REFERENCES merchants(id),
  external_customer_id TEXT,
  email TEXT,
  telegram_id TEXT,
  created_at TIMESTAMP NOT NULL DEFAULT now()
);

CREATE TABLE merchant_orders (
  id UUID PRIMARY KEY,
  merchant_id UUID NOT NULL REFERENCES merchants(id),
  customer_id UUID REFERENCES customers(id),
  external_order_id TEXT NOT NULL,
  amount NUMERIC(20, 8) NOT NULL,
  currency TEXT NOT NULL,
  status TEXT NOT NULL DEFAULT 'pending',
  fulfillment_status TEXT NOT NULL DEFAULT 'not_started',
  created_at TIMESTAMP NOT NULL DEFAULT now(),
  UNIQUE (merchant_id, external_order_id)
);

CREATE TABLE payment_sessions (
  id UUID PRIMARY KEY,
  merchant_id UUID NOT NULL REFERENCES merchants(id),
  order_id UUID REFERENCES merchant_orders(id),
  oxapay_track_id TEXT UNIQUE,
  payment_type TEXT NOT NULL, -- invoice, white_label, static_address
  payment_url TEXT,
  expected_amount NUMERIC(20, 8),
  expected_currency TEXT,
  selected_coin TEXT,
  selected_network TEXT,
  oxapay_status TEXT,
  internal_status TEXT NOT NULL DEFAULT 'created',
  expires_at TIMESTAMP,
  created_at TIMESTAMP NOT NULL DEFAULT now(),
  updated_at TIMESTAMP NOT NULL DEFAULT now()
);

CREATE TABLE payment_events (
  id UUID PRIMARY KEY,
  merchant_id UUID NOT NULL REFERENCES merchants(id),
  payment_session_id UUID REFERENCES payment_sessions(id),
  oxapay_track_id TEXT,
  event_type TEXT NOT NULL,
  oxapay_status TEXT,
  payload_hash TEXT NOT NULL,
  raw_payload JSONB NOT NULL,
  received_at TIMESTAMP NOT NULL DEFAULT now(),
  UNIQUE (merchant_id, payload_hash)
);

CREATE TABLE support_cases (
  id UUID PRIMARY KEY,
  merchant_id UUID NOT NULL REFERENCES merchants(id),
  payment_session_id UUID REFERENCES payment_sessions(id),
  order_id UUID REFERENCES merchant_orders(id),
  customer_id UUID REFERENCES customers(id),
  case_type TEXT NOT NULL,
  priority TEXT NOT NULL DEFAULT 'normal',
  status TEXT NOT NULL DEFAULT 'open',
  assigned_to TEXT,
  summary TEXT,
  resolution TEXT,
  created_at TIMESTAMP NOT NULL DEFAULT now(),
  resolved_at TIMESTAMP
);

CREATE TABLE support_case_notes (
  id UUID PRIMARY KEY,
  case_id UUID NOT NULL REFERENCES support_cases(id),
  author_type TEXT NOT NULL, -- system, agent, developer, finance
  note TEXT NOT NULL,
  created_at TIMESTAMP NOT NULL DEFAULT now()
);

CREATE TABLE webhook_delivery_logs (
  id UUID PRIMARY KEY,
  merchant_id UUID NOT NULL REFERENCES merchants(id),
  oxapay_track_id TEXT,
  received BOOLEAN NOT NULL DEFAULT false,
  verified BOOLEAN NOT NULL DEFAULT false,
  processed BOOLEAN NOT NULL DEFAULT false,
  error_message TEXT,
  received_at TIMESTAMP NOT NULL DEFAULT now()
);

This schema is intentionally support-oriented.

It does not only store payments.

It stores the evidence support agents need to reason about payment cases.

Internal status mapping

Do not expose raw gateway statuses directly to non-technical support agents.

Create an internal status layer.

Example:

type InternalPaymentStatus =
  | 'created'
  | 'awaiting_customer_action'
  | 'payment_detected'
  | 'fully_paid'
  | 'partially_paid'
  | 'expired_without_payment'
  | 'refund_in_progress'
  | 'refunded'
  | 'manual_review_required'
  | 'unknown';

function mapOxaPayStatus(status: string): InternalPaymentStatus {
  switch (status) {
    case 'new':
      return 'created';
    case 'waiting':
      return 'awaiting_customer_action';
    case 'paying':
      return 'payment_detected';
    case 'paid':
    case 'manual_accept':
      return 'fully_paid';
    case 'underpaid':
      return 'partially_paid';
    case 'expired':
      return 'expired_without_payment';
    case 'refunding':
      return 'refund_in_progress';
    case 'refunded':
      return 'refunded';
    default:
      return 'unknown';
  }
}

Why do this?

Because support agents need operational meaning, not raw API vocabulary.

For example, paying may mean “payment activity has been detected, but do not fulfill yet.”

paid means the merchant system can move toward fulfillment.

underpaid means support should review whether the customer needs to complete payment, receive instructions, or be escalated according to the merchant's policy.

Issue taxonomy

A good support desk should create issue categories automatically.

Here is a practical taxonomy.

1. Paid but not fulfilled

Payment reached final paid status, but the merchant order was not delivered or activated.

Likely causes:

fulfillment service failed,
webhook was processed but downstream job failed,
order mapping failed,
product inventory logic failed,
manual review flag blocked delivery.

Agent action:

confirm payment,
retry fulfillment,
escalate to operations if retry fails.

2. Payment detected but not final

Payment activity exists, but the status is not final.

Likely causes:

still awaiting confirmation,
underpayment risk,
customer payment in progress,
network delay.

Agent action:

do not manually fulfill unless policy allows,
send a waiting message,
monitor status.

3. Underpaid invoice

The customer paid less than required.

Likely causes:

network fee misunderstanding,
wrong amount entered,
exchange withdrawal fee deducted,
customer sent partial funds.

Agent action:

explain underpayment,
ask customer to complete payment if the system supports it,
escalate based on merchant policy.

4. Expired invoice

The invoice expired before payment completion.

Likely causes:

customer abandoned payment,
payment sent too late,
network delay,
user copied payment details but paid after expiry.

Agent action:

check Payment Information,
check Payment History if needed,
issue new invoice if policy allows,
escalate late-payment cases.

5. Webhook received but not processed

The support desk has a verified webhook, but the merchant app did not update the order.

Likely causes:

merchant app returned error,
database error,
fulfillment job failed,
idempotency bug,
queue failure.

Agent action:

retry internal processing,
escalate to developer,
notify merchant operations.

6. No webhook but payment exists

Payment exists when queried, but no webhook event exists in your local event store.

Likely causes:

callback URL misconfigured,
endpoint downtime,
webhook rejected,
network or TLS issue,
missed delivery.

Agent action:

create event from verified Payment Information lookup,
run backfill,
flag callback health issue.

7. Static address payment needs matching

A payment arrived to a static address, but the business action is unclear.

Likely causes:

customer used a deposit address outside the intended flow,
missing memo/order reference,
top-up not mapped to the right account,
amount does not match expected deposit.

Agent action:

match by track ID, customer, amount, and time,
escalate unresolved deposits,
avoid automatic fulfillment if confidence is low.

8. Customer used wrong instructions

The customer claims payment but the available data does not match the invoice.

Likely causes:

wrong network,
wrong coin,
wrong amount,
old invoice URL,
payment sent outside the expected flow.

Agent action:

ask for transaction details,
check merchant policy,
escalate carefully.

This taxonomy is one of the most valuable parts of the product.

The more cases you classify automatically, the less support time the merchant wastes.

Creating an invoice with support metadata

Your support desk becomes more useful if it is involved when the payment session is created.

Here is a simplified Node.js example.

import express from 'express';
import crypto from 'crypto';

const app = express();

const OXAPAY_BASE_URL = 'https://api.oxapay.com/v1';
const MERCHANT_API_KEY = process.env.OXAPAY_MERCHANT_API_KEY;
const PUBLIC_BASE_URL = process.env.PUBLIC_BASE_URL;

app.use(express.json());

app.post('/api/orders/:orderId/pay', async (req, res) => {
  const { orderId } = req.params;

  // Load the order from your merchant database.
  const order = await db.orders.findById(orderId);

  if (!order) {
    return res.status(404).json({ error: 'Order not found' });
  }

  const response = await fetch(`${OXAPAY_BASE_URL}/payment/invoice`, {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      'merchant_api_key': MERCHANT_API_KEY,
    },
    body: JSON.stringify({
      amount: order.amount,
      currency: order.currency || 'USD',
      order_id: order.externalOrderId,
      callback_url: `${PUBLIC_BASE_URL}/webhooks/oxapay/payment`,
      return_url: `${PUBLIC_BASE_URL}/orders/${order.id}/payment-status`,
      description: `Payment for order ${order.externalOrderId}`,
    }),
  });

  const data = await response.json();

  if (!response.ok) {
    return res.status(502).json({ error: 'Could not create payment invoice', details: data });
  }

  await db.paymentSessions.insert({
    orderId: order.id,
    oxapayTrackId: data?.data?.track_id,
    paymentUrl: data?.data?.payment_url,
    expectedAmount: order.amount,
    expectedCurrency: order.currency || 'USD',
    internalStatus: 'created',
    rawResponse: data,
  });

  res.json({
    paymentUrl: data?.data?.payment_url,
    trackId: data?.data?.track_id,
  });
});

In production, adjust field names to the exact response object returned by the API version you use.

The principle is what matters:

store the OxaPay track_id,
connect it to the merchant order,
store the expected amount,
store the customer context,
and configure a webhook URL that your support desk can observe.

Webhook receiver with HMAC validation

Webhook security is not optional.

OxaPay's SDK documentation describes HMAC validation using SHA-512 over the raw request body. That means you should verify the signature before trusting the payload.

In Express, use a raw body parser for the webhook route.

import express from 'express';
import crypto from 'crypto';

const app = express();
const MERCHANT_API_KEY = process.env.OXAPAY_MERCHANT_API_KEY;

app.post(
  '/webhooks/oxapay/payment',
  express.raw({ type: 'application/json' }),
  async (req, res) => {
    const receivedHmac = req.header('HMAC');
    const rawBody = req.body;

    const calculatedHmac = crypto
      .createHmac('sha512', MERCHANT_API_KEY)
      .update(rawBody)
      .digest('hex');

    const valid = safeCompare(receivedHmac, calculatedHmac);

    if (!valid) {
      await db.webhookDeliveryLogs.insert({
        received: true,
        verified: false,
        errorMessage: 'Invalid HMAC signature',
      });

      return res.status(401).send('invalid signature');
    }

    const payload = JSON.parse(rawBody.toString('utf8'));
    const payloadHash = crypto.createHash('sha256').update(rawBody).digest('hex');

    try {
      await ingestPaymentWebhook(payload, payloadHash);
      res.status(200).send('ok');
    } catch (error) {
      await db.webhookDeliveryLogs.insert({
        received: true,
        verified: true,
        processed: false,
        oxapayTrackId: payload.track_id || payload.trackId,
        errorMessage: error.message,
      });

      // Return 500 only if you intentionally want the provider to retry.
      return res.status(500).send('processing error');
    }
  }
);

function safeCompare(a, b) {
  if (!a || !b) return false;

  const aBuffer = Buffer.from(a, 'hex');
  const bBuffer = Buffer.from(b, 'hex');

  if (aBuffer.length !== bBuffer.length) return false;

  return crypto.timingSafeEqual(aBuffer, bBuffer);
}

The exact header casing and payload field names should be verified against the current OxaPay documentation and your integration tests.

The important practices are stable:

verify HMAC,
use the raw body,
deduplicate events,
record failed processing,
and return the correct HTTP response based on whether you want a retry.

Webhook ingestion logic

A support desk should treat webhook events as immutable evidence.

Do not overwrite history.

Append events.

Then update the current payment state.

async function ingestPaymentWebhook(payload, payloadHash) {
  const trackId = String(payload.track_id || payload.trackId || payload.id || '');

  if (!trackId) {
    throw new Error('Webhook payload missing track_id');
  }

  const existing = await db.paymentEvents.findByPayloadHash(payloadHash);

  if (existing) {
    return; // idempotent duplicate delivery
  }

  const session = await db.paymentSessions.findByTrackId(trackId);

  await db.paymentEvents.insert({
    paymentSessionId: session?.id || null,
    oxapayTrackId: trackId,
    eventType: 'oxapay.payment.webhook',
    oxapayStatus: payload.status,
    payloadHash,
    rawPayload: payload,
  });

  if (!session) {
    await createSupportCase({
      caseType: 'unknown_payment_reference',
      priority: 'high',
      summary: `Webhook received for unknown track_id ${trackId}`,
      rawPayload: payload,
    });

    return;
  }

  const internalStatus = mapOxaPayStatus(payload.status);

  await db.paymentSessions.update(session.id, {
    oxapayStatus: payload.status,
    internalStatus,
    updatedAt: new Date(),
  });

  await classifyPaymentCase(session.id);
}

The support desk should never assume a single webhook is the whole truth.

It is an event.

Your system still needs lookup, backfill, and reconciliation.

Payment information lookup

Support agents need a “refresh from provider” button.

When a ticket is opened, the agent should be able to query the latest payment information by track_id.

async function refreshPaymentInformation(trackId) {
  const response = await fetch(`${OXAPAY_BASE_URL}/payment/${trackId}`, {
    method: 'GET',
    headers: {
      'Content-Type': 'application/json',
      'merchant_api_key': MERCHANT_API_KEY,
    },
  });

  const data = await response.json();

  if (!response.ok) {
    throw new Error(`Payment information lookup failed: ${JSON.stringify(data)}`);
  }

  await db.paymentProviderSnapshots.insert({
    trackId,
    provider: 'oxapay',
    rawResponse: data,
    fetchedAt: new Date(),
  });

  const providerPayment = data?.data || data;

  await db.paymentSessions.updateByTrackId(trackId, {
    oxapayStatus: providerPayment.status,
    internalStatus: mapOxaPayStatus(providerPayment.status),
    selectedCoin: providerPayment.coin,
    selectedNetwork: providerPayment.network,
    updatedAt: new Date(),
  });

  return providerPayment;
}

This is especially useful when:

the merchant missed a webhook,
the agent wants the latest state,
a customer claims the payment changed,
or a case has been open for too long.

Payment history backfill

The support desk should run a scheduled sync job.

OxaPay's Payment History endpoint supports filters such as time range, payment status, payment type, amount, and pagination.

That makes it useful for backfilling records.

async function backfillRecentPayments({ from, to, page = 1 }) {
  const params = new URLSearchParams({
    from: from.toISOString(),
    to: to.toISOString(),
    page: String(page),
    size: '100',
  });

  const response = await fetch(`${OXAPAY_BASE_URL}/payment?${params}`, {
    method: 'GET',
    headers: {
      'Content-Type': 'application/json',
      'merchant_api_key': MERCHANT_API_KEY,
    },
  });

  const data = await response.json();

  if (!response.ok) {
    throw new Error(`Payment history backfill failed: ${JSON.stringify(data)}`);
  }

  const payments = data?.data?.items || data?.data || [];

  for (const payment of payments) {
    await upsertPaymentFromProviderHistory(payment);
  }

  return payments.length;
}

Do not rely only on the exact query parameter names in this sample. Confirm the current API schema in the OxaPay docs and adapt the code accordingly.

The pattern is the important part:

fetch recent payment history,
compare provider state with local state,
create missing sessions,
flag mismatches,
and open support cases when needed.

Classification engine

The classification engine is the heart of the product.

It turns raw payment data into support work.

async function classifyPaymentCase(paymentSessionId) {
  const session = await db.paymentSessions.findById(paymentSessionId);
  const order = session.orderId
    ? await db.orders.findById(session.orderId)
    : null;

  if (!order) {
    return createOrUpdateCase({
      paymentSessionId,
      caseType: 'payment_without_order_match',
      priority: 'high',
      summary: 'Payment session has no matching merchant order.',
    });
  }

  if (session.internalStatus === 'fully_paid' && order.fulfillmentStatus !== 'completed') {
    return createOrUpdateCase({
      paymentSessionId,
      orderId: order.id,
      caseType: 'paid_not_fulfilled',
      priority: 'high',
      summary: 'Payment is fully paid, but fulfillment has not completed.',
    });
  }

  if (session.internalStatus === 'partially_paid') {
    return createOrUpdateCase({
      paymentSessionId,
      orderId: order.id,
      caseType: 'underpaid_invoice',
      priority: 'normal',
      summary: 'Invoice is underpaid and needs merchant policy review.',
    });
  }

  if (session.internalStatus === 'expired_without_payment' && order.status === 'pending') {
    return createOrUpdateCase({
      paymentSessionId,
      orderId: order.id,
      caseType: 'expired_invoice',
      priority: 'low',
      summary: 'Invoice expired before payment was completed.',
    });
  }

  if (session.internalStatus === 'payment_detected') {
    return createOrUpdateCase({
      paymentSessionId,
      orderId: order.id,
      caseType: 'payment_detected_not_final',
      priority: 'normal',
      summary: 'Payment activity detected but not final yet.',
    });
  }

  return null;
}

This is where your product becomes more than a dashboard.

It starts doing operational triage.

Agent dashboard design

A useful support desk dashboard should not look like a developer log viewer.

It should answer support questions quickly.

Each payment page should show:

Payment summary

customer,
order ID,
amount,
invoice type,
OxaPay track_id,
current status,
selected coin,
selected network,
created time,
expiry time,
final paid time if available.

Operational state

order status,
fulfillment status,
webhook status,
issue category,
support priority,
assigned agent,
escalation state.

Timeline

A chronological list of:

invoice creation,
customer actions,
provider status changes,
webhook deliveries,
internal processing,
fulfillment attempts,
support notes,
escalation events,
resolution.

Recommended action

For example:

“Wait for final paid status.”
“Retry fulfillment.”
“Ask customer to complete underpaid invoice.”
“Create a new invoice.”
“Escalate to developer: webhook processed but fulfillment failed.”
“Escalate to finance: static address deposit needs manual matching.”

Response templates

Support agents should be able to copy safe customer messages.

This prevents inconsistent explanations.

Customer-facing payment status page

One of the most underrated features is a customer-facing status page.

Instead of asking the customer to open a ticket immediately, give them a link like:

/orders/ORD-12903/payment-status

The page should show:

invoice status,
whether payment is still waiting,
whether payment activity has been detected,
whether the invoice expired,
whether support review is needed,
and what the customer should do next.

Do not expose sensitive internal logs.

Do not expose API payloads.

Do not expose private notes.

Show only safe, customer-readable information.

Example status message:

We have detected payment activity for this invoice, but the payment has not reached the final paid status yet. Your order will be updated automatically once the payment is completed.

Another example:

This invoice expired before full payment was completed. If you believe you already paid, please contact support with your transaction details.

This can reduce duplicate tickets.

Support response templates

Your product can include templates by case type.

Payment detected but not final

Thanks for your message. We can see payment activity for your invoice, but the payment has not reached the final paid status yet. We are monitoring it and your order will update once the payment is completed.

Paid but not fulfilled

Your payment has been received. The order delivery step did not complete automatically, so our team is reviewing it now. We will update your order as soon as possible.

Underpaid invoice

The payment received for this invoice is lower than the expected amount. Our team needs to review the payment before the order can be completed. We will contact you with the next step.

Expired invoice

This invoice expired before payment was completed. Please create a new payment request from the checkout page, or contact support if you already sent funds.

Unknown transaction claim

We could not match the information provided to an active invoice yet. Please send the transaction hash, coin, network, amount, and approximate payment time so our team can review it.

These templates are not just convenience features.

They reduce support mistakes.

Permission model

Payment support tools should have strict permissions.

Recommended roles:

Viewer

Can view payment status, timeline, and public-safe information.

Cannot edit cases or trigger actions.

Support Agent

Can add notes, change case status, send templates, and escalate cases.

Cannot edit financial data or trigger payouts.

Operations Manager

Can resolve cases, retry fulfillment, approve manual review, and export reports.

Developer Admin

Can view webhook logs, API errors, payload metadata, and integration health.

Finance Admin

Can export reports and review refund/payout-related cases.

Your MVP can start with fewer roles, but do not give every support agent access to everything.

Crypto payment support involves sensitive financial data.

Security requirements

A support desk handles payment data, customer data, API credentials, and operational decisions.

Security cannot be an afterthought.

Minimum requirements:

Encrypt API keys at rest.
Verify webhook HMAC signatures.
Store raw webhook payloads carefully.
Mask sensitive data in the UI.
Use role-based access control.
Keep audit logs for case actions.
Do not let support agents trigger payouts unless intentionally designed.
Use idempotency for processing repeated events.
Rate-limit public status pages.
Avoid exposing internal provider payloads to customers.
Log access to payment records.
Separate production and test environments.

Also be careful with customer-submitted transaction details.

A customer may paste wallet addresses, transaction hashes, screenshots, emails, or other sensitive data into a ticket.

Treat support records as sensitive operational data.

Integration with existing support tools

You do not need to replace Zendesk, Intercom, Freshdesk, Help Scout, Crisp, or a merchant's existing support stack.

A better MVP is to integrate with them.

Your product can:

create internal support cases,
generate a support link,
push a summary into an existing ticket,
attach payment status to a ticket,
add private notes,
or send agent response templates.

For example:

Customer ticket in Intercom
        ↓
Agent enters order ID
        ↓
Your tool finds payment session
        ↓
Your tool classifies issue
        ↓
Agent copies recommended response
        ↓
Case remains linked for audit

This approach is easier to sell.

Merchants do not need to migrate their support team.

They just add crypto payment intelligence to the workflow they already use.

Low-code version

This product can also be offered as a lower-cost service with Make or n8n.

For example:

OxaPay payment webhook
        ↓
Make or n8n scenario
        ↓
Search payment/order record
        ↓
Classify status
        ↓
Create ticket in support tool
        ↓
Notify Telegram/Slack
        ↓
Update Google Sheet or Airtable

OxaPay's Make integration includes modules for payment webhooks, invoice generation, payment information, payment search, payout actions, static addresses, and other payment operations.

That means developers can sell three product tiers:

Template setup for very small merchants.
Managed automation for growing merchants.
Custom support desk SaaS for higher-volume merchants.

This is a good business model because not every merchant needs a full SaaS product on day one.

MVP scope

Do not start by building a full support platform.

Start with a narrow tool.

A strong MVP includes:

merchant connection,
invoice/order mapping,
webhook receiver,
HMAC validation,
payment event storage,
payment search,
payment timeline,
issue classification for 5 core cases,
manual case notes,
customer-safe status messages,
and a simple daily unresolved-cases report.

The first five case types should be:

paid but not fulfilled,
payment detected but not final,
underpaid invoice,
expired invoice,
webhook received but fulfillment failed.

Do not build refund workflows, payout workflows, multi-agent routing, or AI support automation in the first version.

Those can come later.

Production version

A production-grade version can add:

multi-merchant support,
multi-agent permissions,
ticketing platform integrations,
static address support,
payout/refund case tracking,
SLA rules,
webhook health monitoring,
automated backfill jobs,
unresolved payment queue,
customer-facing status pages,
merchant analytics,
finance exports,
support macros,
internal escalation workflows,
audit logs,
and anomaly detection.

An advanced version can also detect patterns:

repeated underpayment from a specific checkout flow,
high expired invoice rate,
webhook delivery failures,
fulfillment failures by product type,
coin/network combinations that cause more support tickets,
and merchants with rising unresolved case volume.

That turns the tool from support desk into payment operations intelligence.

Revenue model

Do not promise guaranteed income.

This is a business model, not a magic income stream.

Developers can monetize it in several ways.

1. Setup fee

Charge merchants to connect OxaPay, order systems, webhooks, and support tooling.

Good for:

custom stores,
SaaS products,
agencies,
high-touch merchants.

2. Monthly support operations subscription

Charge a monthly fee for the dashboard, monitoring, and unresolved case queue.

Good for:

merchants with recurring crypto payment volume,
digital commerce,
hosting,
SaaS,
communities.

3. Per-agent pricing

Charge based on support team seats.

Good for:

larger merchants,
marketplaces,
agencies handling multiple clients.

4. Managed support add-on

Offer hands-on monitoring, weekly reports, and escalation support.

Good for:

merchants without technical staff,
non-technical founders,
agencies.

5. Agency license

Sell the tool to agencies that manage crypto payment integrations for multiple clients.

Good for:

web agencies,
ecommerce agencies,
payment integration consultants.

Example positioning:

We help crypto-accepting merchants reduce payment support confusion by giving their agents a searchable payment timeline, issue classification, and customer-safe response templates.

That is much stronger than:

We integrate a crypto payment gateway.

Pricing examples

These are not guarantees.

They are positioning examples.

Small merchant package

$300-$800 setup
$49-$149/month monitoring and support dashboard

Best for:

small digital stores,
solo founders,
course sellers,
communities.

Growing merchant package

$1,000-$3,000 setup
$199-$499/month operations dashboard + ticketing integration

Best for:

SaaS,
hosting,
subscription communities,
stores with regular crypto order volume.

Agency or multi-client package

$2,000-$5,000 implementation
$500+/month for multi-client support, reporting, and maintenance

Best for:

agencies,
payment consultants,
businesses managing multiple merchant accounts.

The real price depends on support volume, integration complexity, security requirements, and how much responsibility you take.

What makes this article idea strong for developers?

Many developer business ideas are too broad.

This one is narrow.

That is a strength.

You are not trying to build a new payment gateway.

You are building a tool around a painful operational workflow.

The buyer already has a reason to care:

customers are confused,
support is slow,
developers are interrupted,
manual checking wastes time,
and payment issues are risky.

The best developer products often come from boring internal problems.

Crypto payment support is one of those problems.

A 21-day build plan

Here is a realistic first build plan.

Days 1-3: Merchant and order model

Build:

merchant account model,
encrypted OxaPay API key storage,
order import or order API,
payment session model,
basic admin login.

Days 4-6: Invoice and webhook layer

Build:

invoice creation,
OxaPay track_id storage,
webhook receiver,
HMAC validation,
raw event storage,
idempotency.

Days 7-9: Timeline and search

Build:

payment search,
order search,
payment timeline,
event list,
provider status display.

Days 10-12: Case classification

Build automatic cases for:

paid but not fulfilled,
payment detected but not final,
underpaid,
expired,
unknown payment reference.

Days 13-15: Agent workflow

Build:

case notes,
case assignment,
case resolution,
priority,
response templates.

Days 16-18: Backfill and refresh

Build:

Payment Information refresh,
Payment History backfill,
mismatch detection,
unresolved case report.

Days 19-21: Packaging and demo

Build:

demo merchant account,
sample payment events,
landing page,
pricing page,
onboarding checklist,
agency demo script.

At the end of 21 days, you should not have a full company.

You should have a sellable prototype.

Demo script for selling it

A good demo should show the pain quickly.

Use this sequence:

Show a customer ticket: “I paid, but my order is still pending.”
Search by order ID.
Open the payment timeline.
Show that payment reached paid.
Show that fulfillment failed.
Create or open the support case.
Copy a safe response template.
Retry fulfillment or escalate.
Show unresolved payment report.

The merchant should immediately understand:

This saves my team time and prevents payment confusion.

That is the sale.

Metrics to track

If you sell this product, track metrics that prove operational value.

Good metrics:

average payment ticket handling time,
number of unresolved payment cases,
paid-but-not-fulfilled cases,
webhook failures,
expired invoice rate,
underpaid invoice rate,
cases resolved without developer escalation,
repeated issue categories,
time from payment to fulfillment,
support tickets per 100 payments.

These metrics help the merchant justify paying for your product.

They also help you improve the product.

Common mistakes

Mistake 1: Building a generic ticketing system

Do not compete with Zendesk or Intercom.

Build payment intelligence.

Mistake 2: Showing raw JSON to support agents

Raw payloads are useful for developers, not agents.

Show plain-language status and timelines.

Mistake 3: Trusting webhooks without verification

Always validate HMAC signatures.

Mistake 4: Depending only on webhooks

Add Payment Information refresh and Payment History backfill.

Mistake 5: Giving support agents dangerous permissions

Do not let support agents trigger financial actions unless the merchant explicitly wants that workflow.

Mistake 6: Ignoring static address complexity

Static addresses are powerful, but deposits may require different matching logic than one-time invoices.

Mistake 7: Promising automatic resolution for every case

Some crypto payment issues require manual review.

Your tool should reduce confusion, not pretend uncertainty does not exist.

Legal and compliance boundaries

Be careful with how you position this product.

You are building support tooling.

You are not necessarily becoming:

a payment processor,
a custodian,
a financial advisor,
a tax advisor,
or the merchant of record.

Your product should help merchants see and manage support cases around payments.

Do not make claims about compliance, chargeback elimination, guaranteed settlement, or legal handling unless you have the proper basis.

For higher-risk flows involving refunds, payouts, customer funds, or revenue splitting, get legal review before positioning the product aggressively.

The final product positioning

A weak pitch:

I built a dashboard for OxaPay payments.

A better pitch:

I built a support desk that helps crypto-accepting merchants investigate payment issues, classify support cases, view payment timelines, and resolve paid-but-not-fulfilled, expired, underpaid, and webhook-related problems faster.

A stronger developer-business pitch:

Crypto checkout is only the first step. Once merchants process real volume, they need support operations around payment status, fulfillment, customer claims, and unresolved cases. A Crypto Payment Support Desk turns OxaPay invoices, webhooks, payment information, and payment history into a support workflow that agents can actually use.

That is the business.

Not another checkout button.

A support layer for merchants who accept crypto payments and need operational clarity.