Connect Paystack to your first Tool Group

• A Tracent account. Sign up at /signup and complete the onboarding wizard so you have an organisation with at least one admin user (you).
• A Paystack test secret key (any account: dashboard > Settings > API Keys & Webhooks > Test secret key, starts with sk_test_). The key is what the gateway will pass to Paystack on your behalf; the test environment is safe to transact against.

From the console, click Servers in the left nav, then Connect a server. The form lives at /console/servers/new.

1. Choose Paystack from the integration list. The card shows the category (Payments) and the market (Nigeria).
2. Give the server a name that makes sense to your team. The default is Paystack; if you operate in multiple Paystack workspaces, name it after the workspace (e.g., Paystack - main store).
3. Paste your Paystack test secret key. The console encrypts it into mcp_servers.oauth_token_encrypted on save; it never appears in the audit log or in any error report.
4. Submit. You land on the new server's detail page at /console/servers/[id].

The server starts in active status with is_verified: false. Verification is automatic once a successful sandbox call has run through; we will get there in step 5.

Click Tool Groups in the left nav. The first time you land at /console/tool-groups the canvas is empty; the centre of the screen shows a + Create your first group button.

A Tool Group is the unit Tracent applies policy to. Tools from any server can belong to any group; one tool can belong to multiple groups. For Paystack the cleanest start is one group: Payments. We will add a second group later if read-only operations want different policy.

1. Click the create button. A new group lands with an inline-editable name.
2. Rename it Payments. Press Enter to commit.
3. The group's coloured dot picks the next colour from the palette; this is purely visual and you can change it later.

The left pane of the composer shows every tool from every registered MCP server, grouped by server. Find the Paystack section and drag the three core tools into the Payments group:

• create_charge: initiate a payment on a customer's card or bank.
• verify_transaction: confirm the status of a previously initiated charge.
• initiate_transfer: send funds out to a beneficiary account.

The composer animates the drop. The Payments group now shows three pinned tools. The group's detail panel on the right stays focused on the group you just edited.

With the Payments group selected, the right pane shows the policy editor. The defaults are sane for a payments group; the three controls to confirm are:

• Allowed roles: admin by default. For a team where developers need to test transfers, add developer. Customer-service and member roles should stay off this group.
• PII mask keys: defaults to bvn, nin, account_number, balance, phone. Leave it alone unless your Paystack workflow uses a non-standard field name; if it does, add it and the gateway redactor picks it up on the next call.
• HITL required: defaults to on. Leave it on; every fund movement waits for a 4-digit PIN. The full walkthrough is in Require human approval for transfers.

Rate limits default to 60 per minute and 1,000 per hour; Paystack's own documented ceilings are well above this so you have headroom. Audit retention defaults to 365 days, which aligns with CBN expectations for financial-event records.

Click Save policy. Every save snapshots the previous state into tool_group_versions; you can restore an earlier version from the History panel on the same screen.

Open Servers, click the Paystack row, then Test this server. You land at /console/servers/[id]/test with a small form.

1. Choose create_charge from the tool dropdown (it populates from the tools you registered in step 3).
2. Paste a representative payload, including at least one PII field so you can see the redactor catch it:

   {
     "amount": 250000,
     "currency": "NGN",
     "reason": "Salary",
     "recipient": {
       "name": "Bashir Yusuf",
       "account_number": "0123456789",
       "bvn": "12345678901",
       "bank_code": "058"
     }
   }

3. Click Run. Because the Payments group has HITL on, the form transitions to the §7.8 gate modal. If this is your first time, the modal asks you to set a 4-digit PIN before approving.
4. Set the PIN, confirm. The modal moves to the transaction-summary view with a 60-second countdown. Enter the PIN, click Approve.

The sandbox returns a stubbed response (the TypeScript gateway runtime is shipping in Phase 1; until then the call is simulated). The important behaviours are visible regardless: the gateway redacted account_number and bvn in gateway_logs.payload_redacted, the row landed with status: success after the PIN approval, and the dashboard counters increment within seconds.

Click Audit log in the left nav. The most recent row is the call you just made. Expand it to see the redacted payload, the latency in milliseconds, the redacted fields, and the correlation ID. If you have multiple test calls, the filters at the top of the page (server, status, date range, redacted-only) help narrow the view; the CSV export at the right of the filter strip downloads everything that matches.

A full tour of the audit log is in Read and export the audit log.

• Configure a Tool Group policy for the full control set, including parameter locks and rate-limit tuning.
• Add a second integration: any African payment rail in the integration directory registers the same way.
• Invite a teammate from /console/teamand assign them the developer role. They will share the Payments group's HITL gate without seeing the Paystack secret key.