Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #16691 > unrolled thread

How does Ecommerce work?

Back to article view | Back to comp.lang.php

Contents

  How does Ecommerce work? bit-naughty@hotmail.com - 2016-03-28 05:21 -0700
    Re: How does Ecommerce work? "J.O. Aho" <user@example.net> - 2016-03-28 15:39 +0200
    Re: How does Ecommerce work? Jerry Stuckle <jstucklex@attglobal.net> - 2016-03-28 15:31 -0400
      Re: How does Ecommerce work? "J.O. Aho" <user@example.net> - 2016-03-29 18:15 +0200
        Re: How does Ecommerce work? Michael Vilain <mev94303y@yahoo.com> - 2016-03-29 09:34 -0700
          Re: How does Ecommerce work? Jerry Stuckle <jstucklex@attglobal.net> - 2016-03-29 12:50 -0400
    Re: How does Ecommerce work? gordonb.yjw6m@burditt.org (Gordon Burditt) - 2016-03-28 19:47 -0500
      Re: How does Ecommerce work? bit-naughty@hotmail.com - 2016-03-29 11:38 -0700
        Re: How does Ecommerce work? Jerry Stuckle <jstucklex@attglobal.net> - 2016-03-29 15:50 -0400
        Re: How does Ecommerce work? gordonb.842wr@burditt.org (Gordon Burditt) - 2016-03-29 15:32 -0500
          Re: How does Ecommerce work? bit-naughty@hotmail.com - 2016-04-01 11:33 -0700
            Re: How does Ecommerce work? Jerry Stuckle <jstucklex@attglobal.net> - 2016-04-01 15:25 -0400
              Re: How does Ecommerce work? "J.O. Aho" <user@example.net> - 2016-04-01 22:19 +0200
        Re: How does Ecommerce work? Richard Yates <richard@yatesguitar.com> - 2016-03-30 08:48 -0700
          Re: How does Ecommerce work? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-03-31 03:34 +0200
            Re: How does Ecommerce work? Jerry Stuckle <jstucklex@attglobal.net> - 2016-03-30 22:37 -0400
            Re: How does Ecommerce work? Richard Yates <richard@yatesguitar.com> - 2016-03-30 21:28 -0700
              Re: How does Ecommerce work? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-03-31 15:33 +0200

#16691 — How does Ecommerce work?

OK, so in Ecommerce, money simply has to be deducted from the customers acct. and added to the merchants, right? So.... is MySQL enough to do this? (as I understand it, a "transactional" Database is what's required....? )
... and how do you make an ecomm site accepting payment, that is to say, integrated with a payment gateway....? I'm specifically interested in NetBanking in India, but I'm guessing it's not too different elsewhere in the world....?


Thanks.

[toc] | [next] | [standalone]

#16692

On 03/28/2016 02:21 PM, bit-naughty@hotmail.com wrote:
> OK, so in Ecommerce, money simply has to be deducted from the customers acct. and added to the merchants, right?

Yes, this is usually done by the PSP like PayPal, Skrill and others.


> So.... is MySQL enough to do this? (as I understand it, a "transactional" Database is what's required....? )

For the transaction, you need to integrate toward the PSP's API.
The database on your side is to keep track of what the merchant has sold
and which transactions has been paid.


> ... and how do you make an ecomm site accepting payment, that is to say, integrated with a payment gateway....?
> I'm specifically interested in NetBanking in India, but I'm guessing it's not too different elsewhere in the world....?

Then contact HDFC Bank, they will provide you with the information you need.

http://www.hdfcbank.com/nri_banking/ways_to_bank/NetBanking/netBanking.htm


-- 

 //Aho

[toc] | [prev] | [next] | [standalone]

#16694

On 3/28/2016 8:21 AM, bit-naughty@hotmail.com wrote:
> OK, so in Ecommerce, money simply has to be deducted from the customers acct. and added to the merchants, right? So.... is MySQL enough to do this? (as I understand it, a "transactional" Database is what's required....? )
> ... and how do you make an ecomm site accepting payment, that is to say, integrated with a payment gateway....? I'm specifically interested in NetBanking in India, but I'm guessing it's not too different elsewhere in the world....?
> 
> 
> Thanks.
> 

In addition to what J.O. said - you need to get someone who really
understands security involved.  It's pretty obvious that you are new to
ECommerce - and it's nothing to fool with.  Hackers all over the world
will do virtually anything to get credit card numbers - and they're much
better at it than the average programmer is at preventing it.  And if
they do break into your site, banks might hold YOU responsible for their
losses.

I've worked on a few ECommerce sites, and have seen literally hundreds
of tries to break in per day - more if we hadn't blocked some IP's.

Security cannot be an afterthought in ECommerce; neither can it be left
to someone not thoroughly versed in security.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#16696

On 03/28/2016 09:31 PM, Jerry Stuckle wrote:
> On 3/28/2016 8:21 AM, bit-naughty@hotmail.com wrote:
>> OK, so in Ecommerce, money simply has to be deducted from the customers acct. and added to the merchants, right? So.... is MySQL enough to do this? (as I understand it, a "transactional" Database is what's required....? )
>> ... and how do you make an ecomm site accepting payment, that is to say, integrated with a payment gateway....? I'm specifically interested in NetBanking in India, but I'm guessing it's not too different elsewhere in the world....?
>>
>>
>> Thanks.
>>
> 
> In addition to what J.O. said - you need to get someone who really
> understands security involved.  It's pretty obvious that you are new to
> ECommerce - and it's nothing to fool with. 

I agree with Jerry, when you look for someone, don't go for the
cheapest, you will not get anyone who is capable, if you want someone in
India who really know their stuff, they cost around the same as
Europeans. I do have a few horror stories from India when it comes to
payment providers, but I can't say more due of NDA.


> Security cannot be an afterthought in ECommerce; neither can it be
> left to someone not thoroughly versed in security.

It do apply to anything involving transactions of money, no matter if
it's ecommerce or something else, just keep in mind to get a good one
who can help you and don't fear the cost, as it will be small compared
to the losses you could do in the future if you use someone who don't know.

-- 

 //Aho

[toc] | [prev] | [next] | [standalone]

#16697

In article <dlvo05FonlkU1@mid.individual.net>,
 "J.O. Aho" <user@example.net> wrote:

> On 03/28/2016 09:31 PM, Jerry Stuckle wrote:
> > On 3/28/2016 8:21 AM, bit-naughty@hotmail.com wrote:
> >> OK, so in Ecommerce, money simply has to be deducted from the customers 
> >> acct. and added to the merchants, right? So.... is MySQL enough to do 
> >> this? (as I understand it, a "transactional" Database is what's 
> >> required....? )
> >> ... and how do you make an ecomm site accepting payment, that is to say, 
> >> integrated with a payment gateway....? I'm specifically interested in 
> >> NetBanking in India, but I'm guessing it's not too different elsewhere in 
> >> the world....?
> >>
> >>
> >> Thanks.
> >>
> > 
> > In addition to what J.O. said - you need to get someone who really
> > understands security involved.  It's pretty obvious that you are new to
> > ECommerce - and it's nothing to fool with. 
> 
> I agree with Jerry, when you look for someone, don't go for the
> cheapest, you will not get anyone who is capable, if you want someone in
> India who really know their stuff, they cost around the same as
> Europeans. I do have a few horror stories from India when it comes to
> payment providers, but I can't say more due of NDA.
> 
> 
> > Security cannot be an afterthought in ECommerce; neither can it be
> > left to someone not thoroughly versed in security.
> 
> It do apply to anything involving transactions of money, no matter if
> it's ecommerce or something else, just keep in mind to get a good one
> who can help you and don't fear the cost, as it will be small compared
> to the losses you could do in the future if you use someone who don't know.

Here in the US, there aren't as many choices.  While the providers 
aren't regulated by the Federal Government like banks, they have to play 
nice with banks so they tend to take what they do very seriously.

Small businesses have either had to deal with a large provider like 
authorize.net or go through the one approved by their bank to process 
payments, which frequently has a financial interest in the bank.  
Sometimes you could get better deals through a large independent 
provider like CostCo, but you had to buy their equipment.  For someone 
like me that didn't charge much, it wasn't worth it.

Then Square, a small independent provider appeared with free readers 
that allowed people and small businesses to charge credit cards from 
their phones.  Other providers are also out there, but I found working 
with Square to fit all my needs.  They even know their stuff when it 
comes to dealing with medical records, so I don't have to worry about 
the HIPPA regulations and leaking info through them.

India and Europe are a whole other matter.  If you're doing this 
research for yourself, ask your bank what providers they work with, hold 
your nose and choose one.  Then choose an e-commerce shopping cart 
package that supports that vendor.  If you're doing research for a 
product, you're duplicating what many other small-time providers have 
done before you.  Good luck with that.

-- 
DeeDee, don't press that button!  DeeDee!  NO!  Dee...
[I filter all Goggle Groups posts, so any reply may be automatically ignored]

[toc] | [prev] | [next] | [standalone]

#16698

On 3/29/2016 12:34 PM, Michael Vilain wrote:
> In article <dlvo05FonlkU1@mid.individual.net>,
>  "J.O. Aho" <user@example.net> wrote:
> 
>> On 03/28/2016 09:31 PM, Jerry Stuckle wrote:
>>> On 3/28/2016 8:21 AM, bit-naughty@hotmail.com wrote:
>>>> OK, so in Ecommerce, money simply has to be deducted from the customers 
>>>> acct. and added to the merchants, right? So.... is MySQL enough to do 
>>>> this? (as I understand it, a "transactional" Database is what's 
>>>> required....? )
>>>> ... and how do you make an ecomm site accepting payment, that is to say, 
>>>> integrated with a payment gateway....? I'm specifically interested in 
>>>> NetBanking in India, but I'm guessing it's not too different elsewhere in 
>>>> the world....?
>>>>
>>>>
>>>> Thanks.
>>>>
>>>
>>> In addition to what J.O. said - you need to get someone who really
>>> understands security involved.  It's pretty obvious that you are new to
>>> ECommerce - and it's nothing to fool with. 
>>
>> I agree with Jerry, when you look for someone, don't go for the
>> cheapest, you will not get anyone who is capable, if you want someone in
>> India who really know their stuff, they cost around the same as
>> Europeans. I do have a few horror stories from India when it comes to
>> payment providers, but I can't say more due of NDA.
>>
>>
>>> Security cannot be an afterthought in ECommerce; neither can it be
>>> left to someone not thoroughly versed in security.
>>
>> It do apply to anything involving transactions of money, no matter if
>> it's ecommerce or something else, just keep in mind to get a good one
>> who can help you and don't fear the cost, as it will be small compared
>> to the losses you could do in the future if you use someone who don't know.
> 
> Here in the US, there aren't as many choices.  While the providers 
> aren't regulated by the Federal Government like banks, they have to play 
> nice with banks so they tend to take what they do very seriously.
> 
> Small businesses have either had to deal with a large provider like 
> authorize.net or go through the one approved by their bank to process 
> payments, which frequently has a financial interest in the bank.  
> Sometimes you could get better deals through a large independent 
> provider like CostCo, but you had to buy their equipment.  For someone 
> like me that didn't charge much, it wasn't worth it.
> 
> Then Square, a small independent provider appeared with free readers 
> that allowed people and small businesses to charge credit cards from 
> their phones.  Other providers are also out there, but I found working 
> with Square to fit all my needs.  They even know their stuff when it 
> comes to dealing with medical records, so I don't have to worry about 
> the HIPPA regulations and leaking info through them.
>

That's great when you have the card.  But it doesn't work for ECommerce.

What's more important in ECommerce is fraud prevention.  Not all CNP
(Card Not Present) processors are the same, and chargeback fees (in
addition to the loss from the transaction) can easily kill all profits.

> India and Europe are a whole other matter.  If you're doing this 
> research for yourself, ask your bank what providers they work with, hold 
> your nose and choose one.  Then choose an e-commerce shopping cart 
> package that supports that vendor.  If you're doing research for a 
> product, you're duplicating what many other small-time providers have 
> done before you.  Good luck with that.
> 

Yes, you need to check closely what providers are good.  Your bank is a
real good start.  But also beware that if the bank has a financial
interest in a provider, that's the one they will recommend.  It may or
may not be the best. http://www.cardnotpresent.com is another good resource.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#16695

> OK, so in Ecommerce, money simply has to be deducted from the
customers acct. and added to the merchants, right?

It sounds simple, but how it's actually done is very different
(consider how people used to do it manually, with checks, cash, and
manually-swiped or inserted credit cards).

> So.... is MySQL enough to do this? 

The banks and the payment processors own the relevant databases,
and even if they happen to use MySQL (which I doubt), they are not
going to let you have direct access to it.

> (as I understand it, a "transactional" Database is what's required....? )

They are still not going to let you get anywhere near it.

> ... and how do you make an ecomm site accepting payment, that is

You need a merchant account with a payment processor.  There are
lots of them and they have different terms (such as fees as a
percentage of the sale, and minimum sale requirements).  Payment
processors provide some sort of program interface for your customers
to buy stuff from you, whether it's a physical point-of-sale terminal
or a program accessed over the Internet.  This is the interface you
need to use.  Don't even think about asking a bank for access to
its database - that's worse than asking for the key to Fort Knox
(where the USA stores gold reserves).

You will need to buy (or rent) some e-commerce software.  It is
obvious from the questions you are asking that you are at least 20
years from writing software that meets the certification standards
required by the banks to handle credit-card information.  (Don't
feel bad ... most programmers have not studied these standards,
much less having the certifications needed.  I could learn how to
do it, but I'm not capable of it now.  That probably applies to
most people in this newsgroup.)

> to say, integrated with a payment gateway....? I'm specifically
> interested in NetBanking in India, but I'm guessing it's not too
> different elsewhere in the world....?

Look for a site that offers web hosting for e-commerce sites.  You
probably want a pre-built store.  You populate the store catalog
with descriptions of merchandise to sell, including images and
prices.  You put your company logo on the web site.  You advertise
the site (and please don't use unsolicited email).  You'll need an
account with a payment processor, but the web site can probably
tell you which processor(s) they work with, and probably give you
some advice on how to get started.  Companies like "Shopify" are
mentioned often.

Customers can go to the site and order stuff.  You don't *EVER* see
a customer credit card number.  The store software will tell you
about orders and whether they have been paid.  You ship the
merchandise.  (Make sure that if you want to sell downloadable
software or music, that the site can handle this.  Also don't get
in trouble with copyright infringement.)  You deal with customer
questions about the merchandise, and deal with merchandise returns.
You may not have a lot of control over whether you can refuse to
allow a return.

Some stores (e.g. Amazon) even allow an arrangement where you stock
their warehouse and they ship the merchandise for you to your
customers.  This probably doesn't come cheap.

Google "e-commerce how to" and "ecommerce platforms".  Beware that
a lot of the advice, especially about trademark registration and
tax laws applies to the USA only, even if they don't say so.  You
may want to add the keyword "India" to the search.

One of the first things to decide on is what you want to sell.  Are
you planning to sell something downloadable or something you have
to ship?  Where can you buy it, and can you buy in large enough
quantities to compete with other sellers?

Think about what currency your prices should be in.  You may want
an account denominated in Indian currency and with a presence in
India if that's where you live (this doesn't prohibit sales to
customers in the USA in dollars, but currency rates fluctuate and
the fees for currency exchange can take a bite out of what you get).
You also might want a company that can give you advice on some of
the legal and tax issues of e-commerce in India.

[toc] | [prev] | [next] | [standalone]

#16699

On Tuesday, March 29, 2016 at 6:17:16 AM UTC+5:30, Gordon Burditt wrote:

I think you guys didn't understand my question.

> Payment
> processors provide some sort of program interface for your customers
> to buy stuff

Yes - if you could post a couple of lines of PHP which do this, I'd be most delighted..... :)
(how does the ecomm website interface with the gateway, and how does the gateway WORK?)

[toc] | [prev] | [next] | [standalone]

#16700

On 3/29/2016 2:38 PM, bit-naughty@hotmail.com wrote:
> On Tuesday, March 29, 2016 at 6:17:16 AM UTC+5:30, Gordon Burditt wrote:
> 
> I think you guys didn't understand my question.
> 
>> Payment
>> processors provide some sort of program interface for your customers
>> to buy stuff
> 
> Yes - if you could post a couple of lines of PHP which do this, I'd be most delighted..... :)
> (how does the ecomm website interface with the gateway, and how does the gateway WORK?)
> 

We understood your question.  But you didn't understand the answer.

And no, we can't provide "a couple of lines of PHP".  The solution is
much more complex than that, requiring several scripts.  And each
gateway has a different interface.

I really suggest you hire someone to do this for you.  What you are
asking for is way over your current capabilities - and very dangerous if
you get it wrong (which you will).

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#16701

> I think you guys didn't understand my question.

They are trying to tell you that what you are attempting to do is
very risky, and you keep asking how to use a nuclear bomb to remove
an infected tooth, ignoring the warnings that you're about to blow
your head off.  You don't seem to be listening.

>> Payment
>> processors provide some sort of program interface for your customers
>> to buy stuff
> 
> Yes - if you could post a couple of lines of PHP which do this, I'd be most delighted..... :)
> (how does the ecomm website interface with the gateway, and how does the gateway WORK?)

If you use non-PCI-certified code to handle credit card numbers,
and you have a security breach, leaking card numbers and perhaps
other details to thieves, you could lose more money than your
ancestors up to 10 generations back earned in their lifetimes.
Maybe much more.

Writing your own code for this is taking an insane risk.

If you just want to see what it's like, without really using the
code on real credit card numbers, go to:

https://github.com/thephpleague/omnipay

scroll down the page, and there's a short example code in PHP, along
with a very long list of payment processors supported.  Also on the
same (very long) page, there's an explanation of how it works.  The
code is open source.

Ideally you want the customer's web browser to send the credit card
details directly to the payment gateway.  The gateway will inform
you whether the payment was successful or not.  The credit card
number should never show up on your server AT ALL.  This is not
what Omnipay does (at least in the example shown) - the credit card
number is in a PHP variable.

[toc] | [prev] | [next] | [standalone]

#16710

On Wednesday, March 30, 2016 at 2:02:47 AM UTC+5:30, Gordon Burditt wrote:

> If you just want to see what it's like, without really using the
> code on real credit card numbers, go to:
> 
> https://github.com/thephpleague/omnipay
> 
> scroll down the page, and there's a short example code in PHP, along
> with a very long list of payment processors supported.  Also on the
> same (very long) page, there's an explanation of how it works.  The
> code is open source.
> 


Aah bro - that helped, greatly! :) However, my PHP knowledge is not at the point where I can decode all of it, but don't worry, I shall sit down with my book and figure it out.

Let me rephrase my question - can anyone explain to me what's happening _at HTTP level_ from the moment the user clicks "Checkout",  till the time he or she gets the "Order Successfully Placed" message? *This* is what I really want to know - after that, coding it in PHP, with or without a library should be easy, or at least easiER than NOT knowing it..... :)
Can anyone help?

[toc] | [prev] | [next] | [standalone]

#16711

On 4/1/2016 2:33 PM, bit-naughty@hotmail.com wrote:
> On Wednesday, March 30, 2016 at 2:02:47 AM UTC+5:30, Gordon Burditt wrote:
> 
>> If you just want to see what it's like, without really using the
>> code on real credit card numbers, go to:
>>
>> https://github.com/thephpleague/omnipay
>>
>> scroll down the page, and there's a short example code in PHP, along
>> with a very long list of payment processors supported.  Also on the
>> same (very long) page, there's an explanation of how it works.  The
>> code is open source.
>>
> 
> 
> Aah bro - that helped, greatly! :) However, my PHP knowledge is not at the point where I can decode all of it, but don't worry, I shall sit down with my book and figure it out.
> 
> Let me rephrase my question - can anyone explain to me what's happening _at HTTP level_ from the moment the user clicks "Checkout",  till the time he or she gets the "Order Successfully Placed" message? *This* is what I really want to know - after that, coding it in PHP, with or without a library should be easy, or at least easiER than NOT knowing it..... :)
> Can anyone help?
> 

It depends on what you're doing as well as the payment processor you're
using.  Every one is different.

And no, even knowing it does NOT make it easy to code, even with a library.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#16712

On 04/01/2016 09:25 PM, Jerry Stuckle wrote:
> On 4/1/2016 2:33 PM, bit-naughty@hotmail.com wrote:
>> On Wednesday, March 30, 2016 at 2:02:47 AM UTC+5:30, Gordon Burditt wrote:
>>
>>> If you just want to see what it's like, without really using the
>>> code on real credit card numbers, go to:
>>>
>>> https://github.com/thephpleague/omnipay
>>>
>>> scroll down the page, and there's a short example code in PHP, along
>>> with a very long list of payment processors supported.  Also on the
>>> same (very long) page, there's an explanation of how it works.  The
>>> code is open source.
>>>
>>
>>
>> Aah bro - that helped, greatly! :) However, my PHP knowledge is not at the point where I can decode all of it, but don't worry, I shall sit down with my book and figure it out.
>>
>> Let me rephrase my question - can anyone explain to me what's happening _at HTTP level_ from the moment the user clicks "Checkout",  till the time he or she gets the "Order Successfully Placed" message? *This* is what I really want to know - after that, coding it in PHP, with or without a library should be easy, or at least easiER than NOT knowing it..... :)
>> Can anyone help?
>>
> 
> It depends on what you're doing as well as the payment processor you're
> using.  Every one is different.

Not all uses http(s) for communication and others have a mix of things,
so yes, it's really different how things works for a PSP and I know some
that has more than one API to use, which can complicate things even more.


> And no, even knowing it does NOT make it easy to code, even with a library.

Some PSP's do supply an example code how to use their service in
different languages, those can help, but still as you said earlier,
better get a professional to do it when you don't know how.

-- 

 //Aho

[toc] | [prev] | [next] | [standalone]

#16702

On Tue, 29 Mar 2016 11:38:12 -0700 (PDT), bit-naughty@hotmail.com
wrote:

>On Tuesday, March 29, 2016 at 6:17:16 AM UTC+5:30, Gordon Burditt wrote:
>
>I think you guys didn't understand my question.
>
>> Payment
>> processors provide some sort of program interface for your customers
>> to buy stuff
>
>Yes - if you could post a couple of lines of PHP which do this, I'd be most delighted..... :)

Sorry that we misunderstood! Try these php lines:

<?php
$goto='https://www.google.com/search?q=internet+merchant+services&ie=utf-8&oe=utf-8';
header("Location:$goto");exit();
?>

[toc] | [prev] | [next] | [standalone]

#16703

Richard Yates wrote:

> <?php
> 
$goto='https://www.google.com/search?q=internet+merchant+services&ie=utf-8&oe=utf-8';
> header("Location:$goto");exit();

The variable is ill-named (PHP >= 5.3 does have a “goto” operator) and 
unnecessary, and ending a PHP script with “exit();” is equivalent to not 
having written “exit();” at all.

<http://php.net/manual/en/control-structures.goto.php>
<http://php.net/manual/en/function.exit.php>

> ?>

Once again: Don’t.

<http://www.php-fig.org/psr/psr-2/#2-2-files>

-- 
PointedEars
Zend Certified PHP Engineer 
<http://www.zend.com/en/yellow-pages/ZEND024953> | Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#16704

On 3/30/2016 9:34 PM, Thomas 'PointedEars' Lahn wrote:
> Richard Yates wrote:
> 
>> <?php
>>
> $goto='https://www.google.com/search?q=internet+merchant+services&ie=utf-8&oe=utf-8';
>> header("Location:$goto");exit();
> 
> The variable is ill-named (PHP >= 5.3 does have a “goto” operator) and 
> unnecessary, and ending a PHP script with “exit();” is equivalent to not 
> having written “exit();” at all.
>

Incorrect.  header() does not stop script execution.  It's always a good
practice to follow it with exit(), even when you don't have any code
following.  That way you won't run into problems should someone add
further code later.

And while it's not necessarily a good idea to call a variable $goto,
GOOD PHP programmers recognize that as a variable, not a command.  Only
trolls and idiots would get them mixed up.  But we all know you are both.

> <http://php.net/manual/en/control-structures.goto.php>
> <http://php.net/manual/en/function.exit.php>
> 
>> ?>
> 
> Once again: Don’t.
> 
> <http://www.php-fig.org/psr/psr-2/#2-2-files>
> 

Once again, not necessary - but a good practice.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#16705

On Thu, 31 Mar 2016 03:34:12 +0200, Thomas 'PointedEars' Lahn
<PointedEars@web.de> wrote:

>Richard Yates wrote:
>
>> <?php
>> 
>$goto='https://www.google.com/search?q=internet+merchant+services&ie=utf-8&oe=utf-8';
>> header("Location:$goto");exit();
>
>The variable is ill-named (PHP >= 5.3 does have a “goto” operator) and 
>unnecessary, and ending a PHP script with “exit();” is equivalent to not 
>having written “exit();” at all.
>
><http://php.net/manual/en/control-structures.goto.php>
><http://php.net/manual/en/function.exit.php>
>
>> ?>
>
>Once again: Don’t.
>
><http://www.php-fig.org/psr/psr-2/#2-2-files>

Unhhh...you do realize that it was a joke, right? 

If I had not defined $goto in one line and used it in the second, it
would not have been "a couple lines of php code" like he asked for,
(You know, so it would be a joke?)

Perhaps you can "include" this line in your personal <head> script:
header("Location:http://www.wikihow.com/Have-a-Sense-of-Humor");exit();

[toc] | [prev] | [next] | [standalone]

#16708

Richard Yates wrote:

> On Thu, 31 Mar 2016 03:34:12 +0200, Thomas 'PointedEars' Lahn
> <PointedEars@web.de> wrote:
>>Richard Yates wrote:
>>> <?php
>>> 
>>$goto='https://www.google.com/search?q=internet+merchant+services&ie=utf-8&oe=utf-8';
>>> header("Location:$goto");exit();
>>The variable is ill-named (PHP >= 5.3 does have a “goto” operator) and
>>unnecessary, and ending a PHP script with “exit();” is equivalent to not
>>having written “exit();” at all.
>>
>><http://php.net/manual/en/control-structures.goto.php>
>><http://php.net/manual/en/function.exit.php>
>>
>>> ?>
>>
>>Once again: Don’t.
>>
>><http://www.php-fig.org/psr/psr-2/#2-2-files>
> 
> Unhhh...you do realize that it was a joke, right?

Sort of, yes.  I did understand the “STFW” part.
 
> If I had not defined $goto in one line and used it in the second, it
> would not have been "a couple lines of php code" like he asked for,
> (You know, so it would be a joke?)

I did not understand your joke *that* way.  They did refer to “Payment 
processors provide some sort of program interface for your customers to buy 
stuff” with “this”, and that is not what your URI, in the “couple lines”, 
refers to.
 
> Perhaps you can "include" this line in your personal <head> script:
> header("Location:http://www.wikihow.com/Have-a-Sense-of-Humor");exit();

Not necessary :)  (You know that <head> has nothing to do with header(), 
yes?)

-- 
PointedEars
Zend Certified PHP Engineer 
<http://www.zend.com/en/yellow-pages/ZEND024953> | Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.php

csiph-web