September 15, 2025 - v1.1.0
Overview
This release introduces webhook support for real-time event notifications and enhanced authentication security features. No breaking changes from v1.0.0.
New Features
1. Webhook Notification System
What's New
Real-time webhook notifications for payment events:
Supported Events:
order.created- New order createdorder.completed- Payment received and confirmedorder.failed- Payment failedorder.cancelled- Order cancelled by merchantrefund.processed- Refund completedpayout.completed- Payout successfully transferred
Webhook Payload Format:
{
"event": "order.completed",
"timestamp": "2025-09-15T14:30:00Z",
"data": {
"order_id": "ord_abc123xyz",
"amount": 100.00,
"currency": "USD",
"status": "completed"
}
}
Impact of Feature
- Eliminates the need for constant polling
- Real-time payment status updates
- Reduces API call volume
- Enables instant customer notifications
- Supports automated workflow triggers
Breaking Changes
None - This is an optional feature. Existing integrations continue to work.
Implementation Reference
→ Documentation coming soon at /api-reference/webhooks
2. HMAC Signature Verification
What's New
Optional HMAC-SHA256 signature verification for webhook security:
New Webhook Header:
X-DVPay-Signature: HMAC signature of request body
Verification Algorithm:
HMAC-SHA256(webhook_secret, request_body)
Impact of Feature
- Prevents webhook spoofing attacks
- Ensures webhook authenticity
- Protects against man-in-the-middle attacks
- Industry-standard security practice
What Might Cause Breaking Changes
- If you enable signature verification, you must verify all incoming webhooks
- Unverified webhooks should be rejected
- Requires webhook secret management in your application
Migration Steps:
- Retrieve webhook secret from the merchant dashboard
- Store webhook secret securely (environment variable)
- Implement HMAC verification in the webhook handler
- Enable signature verification in dashboard settings
Implementation Reference
→ Documentation coming soon at /api-reference/webhooks#security
3. IP Whitelist Configuration
What's New
Configure IP whitelist for enhanced API security:
Features:
- Add up to 10 IP addresses or CIDR ranges
- Requests from non-whitelisted IPs are rejected
- Configure via the merchant dashboard
- Separate whitelists for API calls and webhooks
Impact of Feature
- Additional layer of security
- Prevents unauthorized API access
- Protects against stolen API keys
- Compliance with security requirements
What Might Cause Breaking Changes
- Once enabled, requests from non-whitelisted IPs will be rejected with 403 Forbidden
- Must add all server IPs before enabling
- Dynamic IPs are not recommended
Implementation Reference
→ Configure in the merchant dashboard under Security Settings
Modifications
1. Enhanced Error Response Format
What's New
Improved error response format with additional context:
Previous Format:
{
"error": "Invalid request"
}
New Format:
{
"error": {
"code": "INVALID_PARAMETER",
"message": "Invalid request",
"field": "amount",
"details": "Amount must be greater than 0"
}
}
Impact of Modification
- More actionable error messages
- Easier debugging for developers
- Field-level error identification
- Consistent error codes across all endpoints
What Might Cause Breaking Changes
- Error response structure changed from string to object
- If you parse
erroras a string, update toerror.message - Error checking logic may need updates
Migration Example:
Before:
if (response.error) {
console.log(response.error);
}
After:
if (response.error) {
console.log(response.error.message);
console.log('Field:', response.error.field);
console.log('Code:', response.error.code);
}
2. Transaction Detail Response Enhancement
What's New
Additional fields in transaction detail response:
New Fields:
payment_method: Payment method used (qr_code, card, etc.)customer_email: Customer email if providedmetadata: Custom metadata attached to orderrefund_history: Array of refund transactionswebhook_attempts: Number of webhook delivery attempts
Impact of Modification
- More comprehensive transaction information
- Better audit trail
- Enhanced reporting capabilities
- Improved customer support workflows
What Might Cause Breaking Changes
None - This is purely additive. All existing fields remain unchanged.
3. Increased Rate Limits
What's New
Increased API rate limits:
Previous Limits:
- 1,000 requests/minute
- 10,000 requests/hour
New Limits:
- 2,000 requests/minute
- 25,000 requests/hour
Impact of Modification
- Better support for high-volume merchants
- Reduced rate limit errors
- Improved scalability
- No changes required to existing integrations
What Might Cause Breaking Changes
None - This is a positive change requiring no action.
Deprecations
1. Legacy Timestamp Format
What's Deprecated
The X-Timestamp header previously accepted both Unix timestamp and ISO 8601 format. ISO 8601 format is now deprecated.
Deprecated (will be removed in v2.0.0):
X-Timestamp: 2025-09-15T14:30:00Z
Preferred (Unix timestamp):
X-Timestamp: 1726408200
Timeline:
- Now: Both formats work (warning logged)
- v1.2.0 (November 2025): Deprecation warning in response headers
- v2.0.0 (March 2026): ISO 8601 format no longer accepted
Impact of Feature
- Standardizes timestamp format
- Improves API consistency
- Reduces parsing complexity
What Might Cause Breaking Changes
After v2.0.0 release, ISO 8601 timestamps will be rejected with 401 Unauthorized.
Migration Steps:
- Update timestamp generation to use Unix format:
Math.floor(Date.now() / 1000) - Test with Unix timestamp format
- Deploy before March 2026
Technical Details
Backward Compatibility
This release is fully backward compatible with v1.0.0. All existing integrations will continue to work without modifications.
Recommended Upgrades
While not required, we recommend:
- Implementing webhook handlers for real-time updates
- Adding HMAC signature verification for security
- Updating error handling for enhanced error format
- Migrating to Unix timestamp format
Migration Checklist
- Review new webhook events and implement handlers (optional)
- Add HMAC signature verification if using webhooks (recommended)
- Update error parsing to handle new error object format
- Migrate timestamp format from ISO 8601 to Unix (required before v2.0.0)
- Configure IP whitelist if additional security needed (optional)
Documentation
- Webhook Documentation (new)
- Security Best Practices (new)
- Error Reference (updated)
- Authentication (updated)