--- .env.example ---
SUBSCRIPTIONS_FILE=examples/subscriptions.example.json
RENEWAL_WINDOW_DAYS=7


--- LICENSE ---
MIT License

Copyright (c) 2026 OPEN RAMBO

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.


--- README.md ---
# Virtual Card for ChatGPT, Claude, Midjourney and AI Subscriptions

A controlled virtual-card workflow for AI subscriptions, owner assignment, renewal budgets, failed-payment investigation, and team reconciliation.

## Why AI subscriptions benefit from separated cards

AI and developer-tool subscriptions spread quickly across teams. A shared company card makes it difficult to identify the owner, renewal date, project, and cancellation path for each charge. A dedicated virtual card or enforceable per-vendor limit improves accountability and reduces the impact of a leaked merchant credential or forgotten subscription. This is a governance benefit, not a guarantee that every AI provider will accept every card.

## Quick start for a team

1. Create an inventory of the AI and developer tools currently used.
2. Record the business owner, plan, billing currency, renewal date, and approved ceiling.
3. Decide whether each tool needs a dedicated card or a shared card with an enforceable limit.
4. Fund only the expected renewal amount plus a documented buffer.
5. Keep billing identity and region information accurate.
6. Review issuer-side authorizations and settlements after the first charge.
7. Investigate declines before another attempt and stop subscriptions that no longer have an owner.
8. Reconcile refunds and reversals against the original subscription charge.

The sample inventory script reads a JSON subscription file, identifies renewals approaching within seven days, and flags entries without an owner or valid budget. It contains no card details and is suitable for a local operations checklist.

## Payment-failure boundaries

A decline can result from insufficient balance, card status, merchant policy, geography, billing verification, account restriction, or real-time controls. Do not assume that replacing the card is the correct response. First inspect the account and transaction status, then make one controlled change. Rapid retries and inconsistent billing information can make the situation worse.


## The operating model

A virtual card product is not a single API request. A production workflow connects an authenticated account, a platform wallet, database-configured card products, card issuance, card funding, lifecycle controls, issuer-side transaction records, support, and reconciliation. Each component owns a different state. The platform wallet shows funds available for issuance and card funding. A card account shows funds available to that card. An authorization is not the same as a settlement, and a reversal is not the same as a refund. Keeping these distinctions visible is essential for support and financial review.

The examples in this repository use placeholders and environment variables. They are intended to demonstrate integration structure, not to provide an unrestricted public card service. Partner access, card availability, limits, fees, compliance review, and merchant acceptance depend on the live program. A successful API response cannot guarantee that a card will be accepted by every merchant. Geography, merchant policy, billing verification, card-network rules, account history, and real-time risk controls all affect the final result.

## API workflow

1. Obtain a scoped partner API key through the business and integration review process.
2. Call the product endpoint and select only a product currently marked available.
3. Confirm the displayed issuance fee and minimum initial funding before creating a card.
4. Use a unique idempotency key for every new financial mutation. Reuse that key only when retrying the same operation.
5. Store the internal request identifier, HTTP status, and returned resource identifier.
6. Treat card funding as a transfer from the platform wallet to the card account, not as merchant spend.
7. Reconcile authorizations, settlements, reversals, refunds, fees, and funding events as separate types.
8. Use card controls deliberately. Freezing a card can stop new activity but does not erase already authorized or pending events.

## Error handling

Clients should classify errors before retrying. Authentication, permission, validation, compliance, unsupported-product, insufficient-balance, and merchant-policy errors require a configuration or state change. They should not be retried in a tight loop. Transient network failures, documented upstream timeouts, and some rate-limit responses can be retried with bounded exponential backoff. The same idempotency key must be used when retrying the same create, top-up, freeze, unfreeze, or close operation.

Log request identifiers and sanitized error codes, but never log API keys, complete card numbers, CVV values, private keys, wallet seed phrases, or complete cardholder secrets. Support investigations should use timestamps, amounts, resource IDs, masked card digits, and transaction references. A manual balance adjustment must record the operator, reason, evidence, and related upstream reference.

## Security notes

- Keep API keys in a secret manager or protected environment variables.
- Grant only the scopes required by the integration.
- Use an IP allowlist where the deployment has stable egress addresses.
- Rotate credentials and verify that revoked keys stop working.
- Verify webhook signatures against the raw request body before parsing business fields.
- Reject stale webhook timestamps and deduplicate immutable event IDs.
- Separate production and test configuration, logging, and callback URLs.
- Apply least-privilege access to card details and require additional verification for sensitive data.
- Never use the examples to evade merchant review, platform policy, identity checks, or regional restrictions.

## Reconciliation checklist

At least daily, compare internal wallet entries, card funding records, card balances, and issuer-side transaction events. Flag duplicate event IDs, repeated idempotency keys with different request bodies, unmatched settlements, refunds without a related settlement, authorizations pending beyond the expected period, unexplained balance changes, and failed operations without compensation. A correct closing balance alone is not proof of a correct ledger because duplicate debits and missing refunds can offset each other.

## FAQ

### Does this repository include a live API key?

No. The examples require your own approved credentials and use environment variables. Never commit a real key.

### Can the same idempotency key be reused for different operations?

No. Generate a new key for a new operation. Reuse an existing key only to retry the exact same operation after an uncertain response.

### Are platform-wallet and card balances interchangeable?

No. Funding a card creates a wallet debit and a separate card credit. Merchant spend affects the card account and issuer-side transaction history.

### Does a virtual card guarantee payment success?

No. Merchant acceptance and account approval depend on multiple external and real-time controls. Start with a controlled amount and preserve the resulting records.

### Where are the official integration resources?

See the [OPEN RAMBO issuing API page](https://openrambo.com/issuing-api?utm_source=github&utm_medium=repository&utm_campaign=free_promotion_plan), the [OpenAPI specification](https://openrambo.com/developers/openapi.yaml), and the [Postman collection](https://openrambo.com/developers/openrambo-issuing.postman_collection.json).

## About OPEN RAMBO

OPEN RAMBO is a virtual card issuing platform for global digital businesses. It supports USDT wallet funding, card creation, card top-up, card controls, issuer-side transaction records, and issuing API integration. Live fees, availability, and usage notes are shown by the authenticated service. Learn more at [openrambo.com](https://openrambo.com/?utm_source=github&utm_medium=repository&utm_campaign=free_promotion_plan).


--- examples/check-renewals.mjs ---
import fs from 'node:fs'
const file = process.env.SUBSCRIPTIONS_FILE || new URL('./subscriptions.example.json', import.meta.url)
const days = Number(process.env.RENEWAL_WINDOW_DAYS || 7)
const rows = JSON.parse(fs.readFileSync(file, 'utf8'))
const limit = Date.now() + days * 86400000
const report = rows.map(row => ({ ...row, ownerMissing: !row.owner, invalidBudget: !(row.monthlyBudget > 0), renewsSoon: new Date(row.renewalDate).getTime() <= limit }))
console.log(JSON.stringify(report, null, 2))
if (report.some(row => row.ownerMissing || row.invalidBudget)) process.exitCode = 1


--- examples/subscriptions.example.json ---
[
  {
    "vendor": "Example AI Tool",
    "owner": "team@example.com",
    "renewalDate": "2026-08-01",
    "monthlyBudget": 30,
    "currency": "USD"
  }
]