Goal
Add consistent, comparable timing logs for outbound payment-provider API/SDK calls so we can monitor performance and troubleshoot slowdowns across providers and payment methods.
Approach
- Introduce shared timing behaviour
- Add an ApiTimings utility to build a standard tag format and emit a single timing log line.
- Store the selected payment method on ProviderConfiguration (via provider factory) so timing code can read it from Context.
- Add a reusable timing wrapper
- Add ApiTimingTrait::timedCall() to wrap a callable, measure elapsed time, and log in a finally block (so failures still get timed).
- Derive processor name from namespace and map provider-specific method names to canonical operations via ApiOperation.
- Instrument provider API classes
- Wrap outbound calls in provider API methods using timedCall(__FUNCTION__, fn () => ...).
- Add/extend ApiOperation mappings for each provider so timing tags use canonical operations.
Results
- Consistent timing log tags across providers and methods:
- Format: [processor|paymentMethod|apiOperation|request|time] <seconds>
- Example: [gravy|cc|authorize|request|time] 1.234567s
- Example: [adyen|cc|authorize|request|time] 1.234567s
- Example: [dlocal|cc|authorize|request|time] 1.234567s
- Example: [braintree|venmo|createsession|request|time] 0.152466s
- Coverage to emit timings for outbound calls added to:
- Gravy
- Adyen
- dLocal
- PayPal
- Braintree
- Provider-specific method mappings added to ApiOperation, ensuring canonical operation names (e.g., authorise, capture, refund, cancel) regardless of provider method naming.
- Tests added/updated for timing utilities/mapping behaviour to keep tags and operation mapping consistent over time.