Don't want to set this up manually? Paste a link to this page into a Devin session and ask it to set everything up for you. A [playbook](/product-guides/creating-playbooks) encodes your team's testing conventions so Devin writes tests the way your engineers do. Payment code has unique concerns — idempotency, currency precision, gateway retries, PCI-safe mocking — so a payments-focused playbook catches issues a generic one would miss. **Option 1: Write the playbook yourself.** Go to [**Settings > Playbooks > Create playbook**](https://app.devin.ai/settings/playbooks/create?utm_source=docs\&utm_medium=use-case-gallery) and define your standards: ```txt Payments Test Playbook theme={null} ## Procedure 1. Read the target payment module and identify all exported functions 2. Study existing test files in src/services/__tests__/ for patterns 3. Create a test file named {Module}.test.ts in __tests__/ next to the source 4. Write tests using the AAA pattern (Arrange, Act, Assert) 5. Mock the Stripe SDK with jest.mock('stripe') — never call real payment APIs 6. Mock database calls with the helpers from src/test/helpers.ts 7. Use integer cents for all currency values — never floating-point dollars 8. Test idempotency: calling processCharge twice with the same idempotency key must not create duplicate charges 9. Cover success paths, error paths, and edge cases for every function 10. Run `npm test -- --coverage` and verify 90%+ line coverage for the file ## Specifications - Framework: Jest with TypeScript - Mocking: jest.mock() for Stripe SDK, jest.spyOn() for internal methods - Currency: Always use integer cents (e.g., 2999 not 29.99) - Assertions: Prefer specific matchers (toHaveBeenCalledWith, toThrow) - Naming: describe('PaymentService') > describe('processCharge') > it('charges a valid card') ## Forbidden Actions - Do not call real Stripe, PayPal, or any live payment gateway in tests - Do not use floating-point arithmetic for currency calculations - Do not modify the source module to make it easier to test - Do not skip idempotency or retry-logic edge cases ``` **Option 2: Let Devin create the playbook for you.** Describe your testing conventions and Devin will generate a complete playbook: ```txt Generate a payments test playbook theme={null} Create a playbook for writing unit tests for our payment modules in src/services/. We use Jest with TypeScript, mock the Stripe SDK with jest.mock('stripe'), and use integer cents for all currency values. Look at our existing tests in src/services/__tests__/ to learn our patterns (AAA style, specific matchers, describe/it naming). The playbook should cover mocking strategy, idempotency testing, currency precision rules, and forbidden actions like calling real payment APIs. ``` Then add your best existing test file (e.g., `src/services/__tests__/UserService.test.ts`) as a [Knowledge](/product-guides/knowledge) entry so Devin has a concrete example of your team's style. Before pointing Devin at specific files, find where the gaps are in your payment modules. Ask Devin to run your coverage tool and surface the worst offenders: ```txt Analyze payment module coverage theme={null} Run npm test -- --coverage and list every file under src/services/ that handles payments, billing, or subscriptions with less than 80% line coverage. Sort by coverage ascending so I can see the biggest gaps first. ``` Devin runs the suite in its terminal, parses the coverage report, and gives you a prioritized list: ``` File | Lines | Uncovered functions ------------------------------------|-------|------------------------------ src/services/PaymentService.ts | 34% | processCharge, issueRefund, handleWebhook src/services/SubscriptionService.ts | 41% | renewSubscription, cancelTrial, proratePlan src/services/InvoiceService.ts | 52% | generateInvoice, applyPromoCode, calculateTax src/services/PayoutService.ts | 58% | initiateTransfer, reconcileSettlement ``` Start a new session, attach your payments test playbook (you'll see a blue pill confirming it's attached), and tell Devin which module to cover: ```txt Write tests for PaymentService theme={null} Write unit tests for all untested functions in src/services/PaymentService.ts. Focus on processCharge, issueRefund, and handleWebhook. Each function needs tests for success, error, and edge cases. Mock the Stripe SDK — never call real APIs. Use integer cents for all currency values. Run the tests and verify 90%+ line coverage for this file. ``` Devin reads the module, studies your existing tests for patterns, writes a comprehensive test file following your playbook, and runs it: ``` PASS src/services/__tests__/PaymentService.test.ts PaymentService processCharge ✓ charges a valid credit card and returns a receipt (14ms) ✓ uses integer cents to avoid floating-point errors (6ms) ✓ rejects duplicate charges with the same idempotency key (5ms) ✓ retries on Stripe gateway timeout up to 3 times (18ms) ✓ throws InsufficientFundsError for declined cards (4ms) issueRefund ✓ refunds full amount for a completed charge (8ms) ✓ refunds partial amount in cents when specified (6ms) ✓ prevents refund exceeding the original charge amount (3ms) ✓ throws AlreadyRefundedError on duplicate refund attempts (4ms) handleWebhook ✓ processes charge.succeeded events and updates order status (7ms) ✓ processes charge.refunded events and credits the customer (6ms) ✓ verifies Stripe webhook signature before processing (3ms) ✓ ignores unrecognized event types without error (2ms) Coverage: 94% lines | 91% branches | 100% functions ``` Devin opens a PR with the test file and a coverage summary in the description. Review the first PR. If the mock strategy or assertion style isn't quite right, update your playbook before running it on more modules — one round of feedback saves you from correcting the same issue across multiple PRs. Then work down your gap list: ```txt Cover SubscriptionService theme={null} Write tests for src/services/SubscriptionService.ts using the same playbook. Focus on renewSubscription, cancelTrial, and proratePlan. Test proration math using integer cents. Target 90%+ line coverage. ``` To go faster, ask Devin to launch parallel sessions — one per payment module — all following the same playbook. Or [schedule](/product-guides/scheduled-sessions) a weekly session that finds any payment modules that have dropped below your coverage threshold and writes tests for them automatically.

{title}