Building secure B2B pricing grids with custom Transients API endpoints and role overrides
Leveraging WordPress Transients for Secure B2B Pricing Grids
When building B2B e-commerce solutions within WordPress, dynamic pricing based on user roles, company affiliations, or custom tiers is a common requirement. Directly querying and calculating prices on every page load can be a performance bottleneck, especially with complex pricing logic. Furthermore, exposing raw pricing data via standard REST API endpoints without proper authorization is a significant security risk. This post details a robust approach using WordPress’s Transients API for caching, coupled with custom REST API endpoints and role-based access control, to deliver secure and performant B2B pricing grids.
Custom REST API Endpoint for Pricing Data
We’ll start by creating a custom REST API endpoint to serve pricing data. This endpoint will be the single source of truth for our pricing grid. To ensure security, we’ll implement checks to verify user authentication and authorization before returning any data.
First, register a new namespace and route within your plugin’s `functions.php` or a dedicated plugin file. We’ll use the `rest_api_init` action hook for this.
Registering the Pricing Endpoint
add_action( 'rest_api_init', function () {
register_rest_route( 'myplugin/v1', '/pricing/(?P<product_id>\d+)', array(
'methods' => WP_REST_Server::READABLE,
'callback' => 'myplugin_get_pricing_data',
'permission_callback' => 'myplugin_check_pricing_permission',
'args' => array(
'product_id' => array(
'required' => true,
'validate_callback' => function( $param, $request, $key ) {
return is_numeric( $param );
}
),
),
) );
} );
Callback Function for Data Retrieval
The callback function, `myplugin_get_pricing_data`, will be responsible for fetching and returning the pricing information. This is where we’ll integrate our transient caching mechanism.
function myplugin_get_pricing_data( WP_REST_Request $request ) {
$product_id = $request->get_param( 'product_id' );
$user_id = get_current_user_id();
$transient_key = 'myplugin_pricing_' . $product_id . '_' . $user_id;
// Attempt to retrieve data from transients
$cached_pricing = get_transient( $transient_key );
if ( false !== $cached_pricing ) {
return new WP_REST_Response( $cached_pricing, 200 );
}
// If not cached, calculate or fetch pricing
$pricing_data = myplugin_calculate_product_pricing( $product_id, $user_id );
// Cache the pricing data for a defined duration (e.g., 1 hour)
// Adjust expiration based on how frequently prices change.
set_transient( $transient_key, $pricing_data, HOUR_IN_SECONDS );
return new WP_REST_Response( $pricing_data, 200 );
}
function myplugin_calculate_product_pricing( $product_id, $user_id ) {
// This is where your complex pricing logic goes.
// It should consider user roles, company, custom tiers, etc.
// Example:
$base_price = get_post_meta( $product_id, '_regular_price', true );
$user_roles = wp_get_current_user()->roles;
$discount = 0;
if ( in_array( 'wholesale_customer', $user_roles ) ) {
$discount = 0.15; // 15% discount for wholesale customers
} elseif ( in_array( 'premium_customer', $user_roles ) ) {
$discount = 0.25; // 25% discount for premium customers
}
$final_price = $base_price * ( 1 - $discount );
// You might also fetch company-specific pricing if applicable
// $company_id = get_user_meta( $user_id, 'company_id', true );
// if ( $company_id ) {
// $company_pricing = get_post_meta( $product_id, '_company_pricing_' . $company_id, true );
// if ( $company_pricing ) {
// $final_price = $company_pricing;
// }
// }
return array(
'product_id' => $product_id,
'base_price' => wc_price( $base_price ), // Assuming WooCommerce context for price formatting
'discount_applied' => $discount * 100 . '%',
'final_price' => wc_price( $final_price ),
'currency' => get_option( 'woocommerce_currency' ),
);
}
Permission Callback for Access Control
The `permission_callback` is crucial for security. It determines who can access this endpoint. We’ll implement checks for logged-in users and potentially specific role capabilities.
function myplugin_check_pricing_permission( WP_REST_Request $request ) {
// Ensure the user is logged in.
if ( ! is_user_logged_in() ) {
return new WP_Error( 'rest_forbidden', esc_html__( 'You must be logged in to view pricing.', 'myplugin' ), array( 'status' => 401 ) );
}
// Optional: Add more granular role checks if needed.
// For example, only allow users with 'customer' role or higher.
$user = wp_get_current_user();
if ( ! $user->has_cap( 'read' ) ) { // 'read' is a common capability for logged-in users
return new WP_Error( 'rest_forbidden', esc_html__( 'You do not have permission to view pricing.', 'myplugin' ), array( 'status' => 403 ) );
}
// You could also check for specific custom roles or capabilities.
// if ( ! user_can( $user->ID, 'view_b2b_pricing' ) ) {
// return new WP_Error( 'rest_forbidden', esc_html__( 'Your role does not permit viewing B2B pricing.', 'myplugin' ), array( 'status' => 403 ) );
// }
return true; // Permission granted
}
Implementing Role-Based Pricing Overrides
The `myplugin_calculate_product_pricing` function is the core of your custom pricing logic. Here, you’ll implement the rules that determine the price for different user segments. This can involve checking user roles, custom user meta (like company ID), or even integrating with external CRM/ERP systems.
Storing Custom Pricing Data
For advanced scenarios, you might need to store specific pricing tiers or overrides that aren’t directly tied to a user’s role but to a company or a specific customer group. This data can be stored as post meta on products, custom tables, or even fetched from an external source.
// Example of fetching company-specific pricing from post meta
// Assuming you have a meta key like '_company_pricing_123' where 123 is the company ID.
$company_id = get_user_meta( $user_id, 'company_id', true );
if ( $company_id ) {
$company_pricing_meta_key = '_company_pricing_' . $company_id;
$company_specific_price = get_post_meta( $product_id, $company_pricing_meta_key, true );
if ( ! empty( $company_specific_price ) ) {
$final_price = $company_specific_price;
// Potentially override other discounts if company pricing is absolute.
}
}
Transient API: Caching for Performance
The Transients API provides a standardized way to cache data in WordPress. It’s ideal for data that doesn’t change frequently but is computationally expensive to generate. In our pricing endpoint, we use transients to store the calculated price for a specific user and product combination.
Transient Key Generation
A well-defined transient key is essential for effective caching. It should be unique for each combination of data that might change. In this case, the product ID and the user ID are the primary factors influencing the price, so we include both in the key.
$transient_key = 'myplugin_pricing_' . $product_id . '_' . $user_id;
Setting and Retrieving Transients
We use `get_transient()` to fetch cached data and `set_transient()` to store it. The third parameter of `set_transient()` is the expiration time in seconds. Choosing an appropriate expiration is a trade-off between performance and data freshness. For pricing, an hour or a few hours is often a reasonable starting point, but this depends heavily on how often prices are updated.
// Retrieve from cache $cached_pricing = get_transient( $transient_key ); // Store in cache set_transient( $transient_key, $pricing_data, HOUR_IN_SECONDS ); // Cache for 1 hour
Cache Invalidation Strategies
When pricing data changes (e.g., a price update, a new discount rule applied globally), you need to invalidate the relevant transients. This can be done manually or programmatically.
- Manual Invalidation: For administrators, you could add a button in the WordPress admin area to clear all pricing transients.
- Programmatic Invalidation: Hook into actions that modify pricing data. For example, when a product price is updated, delete the transients associated with that product.
/**
* Example: Invalidate transients when a product is updated.
*/
add_action( 'save_post', function( $post_id ) {
// Check if it's a product post type and not an autosave
if ( 'product' !== get_post_type( $post_id ) || defined( 'DOING_AUTOSAVE' ) || DOING_AUTOSAVE ) {
return;
}
// Get all users who might have cached pricing for this product.
// This can be inefficient if you have many users. A better approach
// might be to store a list of users affected by a price change.
$users = get_users( array( 'fields' => 'ID' ) );
foreach ( $users as $user_id ) {
$transient_key = 'myplugin_pricing_' . $post_id . '_' . $user_id;
delete_transient( $transient_key );
}
// Also consider clearing transients for company-specific pricing if applicable.
// You'd need to know which companies are associated with this product.
} );
/**
* Example: Function to manually clear all pricing transients.
*/
function myplugin_clear_all_pricing_transients() {
global $wpdb;
// This is a more aggressive approach and might require careful consideration.
// It's better to target specific transients if possible.
$wpdb->query( $wpdb->prepare( "DELETE FROM {$wpdb->options} WHERE option_name LIKE %s", '_transient_myplugin_pricing_%' ) );
$wpdb->query( $wpdb->prepare( "DELETE FROM {$wpdb->options} WHERE option_name LIKE %s", '_transient_timeout_myplugin_pricing_%' ) );
}
// You would hook this function to an admin action, e.g., a button click.
Frontend Integration
On the frontend, your JavaScript code will make AJAX requests to this custom REST API endpoint to fetch pricing information. This keeps the pricing logic server-side and ensures that only authorized users can access it.
// Example JavaScript using fetch API
document.addEventListener('DOMContentLoaded', function() {
const productId = document.querySelector('.product-id').value; // Assuming product ID is available in a hidden input
fetch(`/wp-json/myplugin/v1/pricing/${productId}`)
.then(response => {
if (!response.ok) {
// Handle errors, e.g., display a message to the user
if (response.status === 401) {
alert('Please log in to see pricing.');
} else if (response.status === 403) {
alert('You do not have permission to view this pricing.');
} else {
alert('An error occurred while fetching pricing.');
}
throw new Error(`HTTP error! status: ${response.status}`);
}
return response.json();
})
.then(data => {
// Update the DOM with pricing information
document.querySelector('.product-price').textContent = data.final_price;
document.querySelector('.base-price').textContent = data.base_price;
document.querySelector('.discount-info').textContent = `Discount: ${data.discount_applied}`;
// Display other pricing details as needed
})
.catch(error => {
console.error('Error fetching pricing:', error);
});
});
Security Considerations and Best Practices
- Never expose raw pricing logic client-side. All calculations and data retrieval should happen on the server.
- Use robust permission checks. The `permission_callback` is your primary defense. Ensure it covers all necessary conditions.
- Sanitize and validate all inputs. Although the REST API handles some validation, always ensure data integrity.
- Choose appropriate transient expiration times. Too short, and you lose performance benefits; too long, and users might see stale data.
- Implement a clear cache invalidation strategy. This is critical for data accuracy.
- Consider rate limiting. For public-facing APIs, rate limiting can prevent abuse. WordPress’s REST API has some built-in rate limiting, but you might need custom solutions for specific endpoints.
- Use HTTPS. Always ensure your WordPress site is served over HTTPS to protect data in transit.
By combining the power of WordPress’s Transients API for efficient caching with custom REST API endpoints and strict role-based access control, you can build secure, performant, and highly customizable B2B pricing grids that meet the complex demands of your clients.