Programmer for Payment Gateway

I have 2 websites.

Site A: This is the main website that I need a CC payment gateway for but this is a black hat niche so no processor will work with me.

Site B: This site will sell a SEO service. This site will be used to register for a payment gateway at stripe for example where it will be accepted.

Now somehow in the backend it will need to be made that once a customer wants to pay on site A with a CC they will fill out the CC form and trough the backend the information will be forwarded to site B to be processed. Therefore allowing CC payment on site A even though it is a blackhat niche.

Ali008 said:

I have 2 websites.

Site A: This is the main website that I need a CC payment gateway for but this is a black hat niche so no processor will work with me.

Site B: This site will sell a SEO service. This site will be used to register for a payment gateway at stripe for example where it will be accepted.

Now somehow in the backend it will need to be made that once a customer wants to pay on site A with a CC they will fill out the CC form and trough the backend the information will be forwarded to site B to be processed. Therefore allowing CC payment on site A even though it is a blackhat niche.

Click to expand...

I know you think you're being very smart here. But the fact is that you aren't.

This is "fronting" or "buffer" and is a very known technique in the Payment Processing World for websites that want to process payments but aren't legally allowed to through the Payment Gateways ToS.

Building a bridge of sorts is very easy - we do it all the time for Stripe, Razorpay, even Paypal etc.

So a user comes to Site A - makes a purchase and then his details are sent to Site B which sends them to the Payment Processor, receives a positive reply and marks the order as complete.

There are a few caveats though.

1. Stripe or any Payment gateway worth it's salt will know the referring URL.
2. Any payment gateway will know the destination URL post submission, unless you're magically cloaking it.

The only way for this would be for you to physically redirect the user.

So, they comes to SiteA.com - make an order. This data is then posted to SiteB.com/receive.php or added to a common database and the visitor is physically redirected to SiteB.com/receive.php where he is shown a button "Complete Payment". Clicking it, he is taken to the Gateway's site or to a form. He completes the payment and is sent to SiteB.com/complete.php with a button that says "Go back to Merchant" which takes him to SiteA.com that shows a complete payment.

No referrers were spoofed in this case. The transaction happened entirely on SiteB.com.

But your URLs were exposed. Your visitors now know that you accept Paypal/Stripe Payments via SiteB.com as a buffer. One report and your account disappears overnight.

So think it through.

Go for a High Risk Payment Gateway.

Or go for "Custom Invoicing". People comes to SiteA.com, place an order. You contact them via email and raise a custom Invoice. They pay it and you then manually mark the order as paid.

BlogPro said:

I know you think you're being very smart here. But the fact is that you aren't.

This is "fronting" or "buffer" and is a very known technique in the Payment Processing World for websites that want to process payments but aren't legally allowed to through the Payment Gateways ToS.

Building a bridge of sorts is very easy - we do it all the time for Stripe, Razorpay, even Paypal etc.

So a user comes to Site A - makes a purchase and then his details are sent to Site B which sends them to the Payment Processor, receives a positive reply and marks the order as complete.

There are a few caveats though.

1. Stripe or any Payment gateway worth it's salt will know the referring URL.
2. Any payment gateway will know the destination URL post submission, unless you're magically cloaking it.

The only way for this would be for you to physically redirect the user.

So, they comes to SiteA.com - make an order. This data is then posted to SiteB.com/receive.php or added to a common database and the visitor is physically redirected to SiteB.com/receive.php where he is shown a button "Complete Payment". Clicking it, he is taken to the Gateway's site or to a form. He completes the payment and is sent to SiteB.com/complete.php with a button that says "Go back to Merchant" which takes him to SiteA.com that shows a complete payment.

No referrers were spoofed in this case. The transaction happened entirely on SiteB.com.

But your URLs were exposed. Your visitors now know that you accept Paypal/Stripe Payments via SiteB.com as a buffer. One report and your account disappears overnight.

So think it through.

Go for a High Risk Payment Gateway.

Or go for "Custom Invoicing". People comes to SiteA.com, place an order. You contact them via email and raise a custom Invoice. They pay it and you then manually mark the order as paid.

Click to expand...

Wow that's a very great insight man... I was going to mention some things, but it seems like you covered everything.

BlogPro said:

I know you think you're being very smart here. But the fact is that you aren't.

This is "fronting" or "buffer" and is a very known technique in the Payment Processing World for websites that want to process payments but aren't legally allowed to through the Payment Gateways ToS.

Building a bridge of sorts is very easy - we do it all the time for Stripe, Razorpay, even Paypal etc.

So a user comes to Site A - makes a purchase and then his details are sent to Site B which sends them to the Payment Processor, receives a positive reply and marks the order as complete.

There are a few caveats though.

1. Stripe or any Payment gateway worth it's salt will know the referring URL.
2. Any payment gateway will know the destination URL post submission, unless you're magically cloaking it.

The only way for this would be for you to physically redirect the user.

So, they comes to SiteA.com - make an order. This data is then posted to SiteB.com/receive.php or added to a common database and the visitor is physically redirected to SiteB.com/receive.php where he is shown a button "Complete Payment". Clicking it, he is taken to the Gateway's site or to a form. He completes the payment and is sent to SiteB.com/complete.php with a button that says "Go back to Merchant" which takes him to SiteA.com that shows a complete payment.

No referrers were spoofed in this case. The transaction happened entirely on SiteB.com.

But your URLs were exposed. Your visitors now know that you accept Paypal/Stripe Payments via SiteB.com as a buffer. One report and your account disappears overnight.

So think it through.

Go for a High Risk Payment Gateway.

Or go for "Custom Invoicing". People comes to SiteA.com, place an order. You contact them via email and raise a custom Invoice. They pay it and you then manually mark the order as paid.

Click to expand...

hey is it possible to help me do this?

Ali008 said:

I have 2 websites.

Site A: This is the main website that I need a CC payment gateway for but this is a black hat niche so no processor will work with me.

Site B: This site will sell a SEO service. This site will be used to register for a payment gateway at stripe for example where it will be accepted.

Now somehow in the backend it will need to be made that once a customer wants to pay on site A with a CC they will fill out the CC form and trough the backend the information will be forwarded to site B to be processed. Therefore allowing CC payment on site A even though it is a blackhat niche.

Click to expand...

As has been said, do not do this, just a waste of time, you need a Black hat acceptable method to take cards.
This is so common and youll lose the account in a matter of days

James2774 said:

As has been said, do not do this, just a waste of time, you need a Black hat acceptable method to take cards.
This is so common and youll lose the account in a matter of days

Click to expand...

do you know any blackhat methods to accept credit cards

vivalikes said:

do you know any blackhat methods to accept credit cards

Click to expand...

It doesn’t really work like that Bc it’s not possible to remove the source.
You’ll always have to direct the customer to the payment method somehow.

I wrote about using a precious metals account to process, that’s def black hat, but gonna cost anywhere from 5-15% and the customer has to go through extra steps.

Same without a service like Paybis.

There is no black hat method possible without some sort of inconvenience really.

I have prior work experience with Payment gateway integration such as Stripe, PayPal & Authorize.net.

I am helping in this area last 7+ years in the verticals domain. Kindly connect over Skype to discuss further.

My Skype is - [email protected]

Thanks