Original Transaction Not Issued For Payment Profile

[glyoder]

The best way for me to explain our problem is by describing how we're authorizing payments and creating payment profiles.

We're creating customer payment profiles in this order:

1. We create a payment nonce using Accept.js

2. We use the payment nonce to perform an authorization for an amount, say $500

3. We use the resulting transaction id to create a payment profiler

4. On the next day, we use the payment profile to CAPTURE the authorized transaction. But now we get an error, "the original transaction was not issued for this payment profile," presumably because the profile was created AFTER the transaction was issued.

Is this a bug or expected behavior?

[glyoder]

OK, I've done some more debugging. I'm only able to capture the originally authorized transaction if I don't associate the transaction with a profile (not surprising).

Associated with payment profile

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<createTransactionRequest xmlns="AnetApi/xml/v1/schema/AnetApiSchema.xsd">
<merchantAuthentication>
<name>****</name>
<transactionKey>*****</transactionKey>
</merchantAuthentication>
<clientId>sdk-java-1.9.2</clientId>
<transactionRequest>
<transactionType>priorAuthCaptureTransaction</transactionType>
<amount>956</amount>
<profile>
<customerProfileId>1810971237</customerProfileId>
<paymentProfile>
<paymentProfileId>1806151346</paymentProfileId>
</paymentProfile>
</profile>
<refTransId>60022499131</refTransId>
</transactionRequest>
</createTransactionRequest>
'
[2017-04-21 09:57:11.702] boot - 8711 DEBUG [pool-25-thread-1] --- HttpCallTask: Raw Response: '<?xml version="1.0" encoding="utf-8"?><createTransactionResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="AnetApi/xml/v1/schema/AnetApiSchema.xsd"><messages><resultCode>Error</resultCode><message><code>E00051</code><text>The original transaction was not issued for this payment profile.</text></message></messages><transactionResponse /></createTransactionResponse>
'
[2017-04-21 09:57:11.705] boot - 8711 DEBUG [http-nio-8443-exec-2] --- HttpUtility: Response: 'net.authorize.api.contract.v1.CreateTransactionResponse@281f5840'
[2017-04-21 09:57:11.706] boot - 8711 DEBUG [http-nio-8443-exec-2] --- ApiOperationBase: Received Response:'net.authorize.api.contract.v1.CreateTransactionResponse@281f5840' for request:'net.authorize.api.contract.v1.CreateTransactionRequest@659ddcaf'
[2017-04-21 09:57:11.706] boot - 8711 DEBUG [http-nio-8443-exec-2] --- ApiOperationBase: Setting response: 'net.authorize.api.contract.v1.CreateTransactionResponse@281f5840'
Failed Transaction.
Error Code: E00051
Error message: The original transaction was not issued for this payment profile.

Not associated with payment profile

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<createTransactionRequest xmlns="AnetApi/xml/v1/schema/AnetApiSchema.xsd">
<merchantAuthentication>
<name>****</name>
<transactionKey>*****</transactionKey>
</merchantAuthentication>
<clientId>sdk-java-1.9.2</clientId>
<transactionRequest>
<transactionType>priorAuthCaptureTransaction</transactionType>
<amount>956</amount>
<refTransId>60022499131</refTransId>
</transactionRequest>
</createTransactionRequest>
'
[2017-04-21 09:58:56.726] boot - 8711 DEBUG [pool-28-thread-1] --- HttpCallTask: Raw Response: '<?xml version="1.0" encoding="utf-8"?><createTransactionResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="AnetApi/xml/v1/schema/AnetApiSchema.xsd"><messages><resultCode>Ok</resultCode><message><code>I00001</code><text>Successful.</text></message></messages><transactionResponse><responseCode>1</responseCode><authCode>NNNGKB</authCode><avsResultCode>P</avsResultCode><cvvResultCode /><cavvResultCode /><transId>60022499131</transId><refTransID>60022499131</refTransID><transHash>4395D736CD1635A173B7517AAEF3200C</transHash><testRequest>0</testRequest><accountNumber>XXXX0027</accountNumber><accountType>Visa</accountType><messages><message><code>1</code><description>This transaction has been approved.</description></message></messages><transHashSha2 /></transactionResponse></createTransactionResponse>
'
[2017-04-21 09:58:56.732] boot - 8711 DEBUG [http-nio-8443-exec-9] --- HttpUtility: Response: 'net.authorize.api.contract.v1.CreateTransactionResponse@6535e9bf'
[2017-04-21 09:58:56.732] boot - 8711 DEBUG [http-nio-8443-exec-9] --- ApiOperationBase: Received Response:'net.authorize.api.contract.v1.CreateTransactionResponse@6535e9bf' for request:'net.authorize.api.contract.v1.CreateTransactionRequest@317294e9'
[2017-04-21 09:58:56.733] boot - 8711 DEBUG [http-nio-8443-exec-9] --- ApiOperationBase: Setting response: 'net.authorize.api.contract.v1.CreateTransactionResponse@6535e9bf'
Successfully created transaction with Transaction ID: 60022499131
Response Code: 1
Message Code: 1
Description: This transaction has been approved.
Auth Code: NNNGKB

[glyoder]

Just to be clear, capturing the prior auth without the payment profile association isn't an acceptable solution for us because that payment doesn't show up in the payment profile history.

[Aaron]

---

@glyoder wrote:

Just to be clear, capturing the prior auth without the payment profile association isn't an acceptable solution for us because that payment doesn't show up in the payment profile history.

---

I'll bring this up internally. What it looks like is happening is that a call to createCustomerProfileFromTransactionRequest just takes the payment information/customer information from the existing transaction and uses that to create a profile, but doesn't retroactively associate the transaction with the profile.

There's a philosophical discussion to be had about what is the expected behavior, since it's not really documented either way. Parsing the name of the function literally, the function is indeed creating a profile from a transaction. The function's not called createCustomerProfileFromTransactionAndThenAssociateThatTransactionWithTheProfileRequest, for example. However, I tend to agree with you that if you're taking an existing transaction and turning it into a profile, my expectation would be that the transaction was then part of the profile record.

So, I don't know if the current behavior was just an oversight in the design or deliberate. It may not even be an easy change on our end depending on how things are architected. If we really want this to be the behavior, we can at least document the limitation on our end.

I'd encourage you to post this onto our Ideas Forum where others can take a look, contribute feedback, and vote for new features. I'll escalate this internally as well.

[Aaron]

Hi @glyoder,

I want to clarify one thing. If you have made your initial authorization request in such a way that it was correctly associated with a profile, you do not have to provide the profile information in the subsequent capture request. If the auth is already associated to the profile, you just need to send the amount and the transaction ID. I want to follow up with my testing of a couple of possible workarounds, to possibly save you a little time.

Option 1 would be to use the nonce you get from Accept.js to create a profile, then do that initial authorization through the profile.

1. Get a nonce.
2. Create a customer profile using that nonce in place of the creditCard data.
3. Charge the customer profile (as auth only) for the transaction.
4. Later, capture the transaction

This is less than ideal because you you create the profile before you've seen whether the first authorization is good or not, so you'd end up with extra profiles for customers that aren't proceeding to the rest of the purchase process.

I don't know why you are doing the auth only followed by a capture, but it might be specifically so that you aren't creating a profile until you know that the card is good. In that case, if you were to do the above, you could just switch to a one-step auth/capture transaction. You'd still probably want to include a followup step of deleting the extraneous profile created for a non-good card.

If you still want to verify that the card is good before creating the profile, Option 2 would be something like the following:

1. Get a nonce

2. Do an auth-only with the nonce

3. If good, create a profile from the transaction, and then void the initial auth.

4. Now redo the auth and capture through the profile.

The drawback with this is that voiding the auth doesn't necessarily remove the hold on funds that was placed on the card when you did the auth. Whether that hold gets removed and when has a lot to do with the card issuer and in some ways is out of our control. If you're talking about small amounts, like $1 or $2, that's probably not a big deal to just let those expire on their own. However, if that initial auth is for any significant amount, you'd probably want to avoid this strategy.

Option 3 would be to do a normal auth-only transaction with the createProfile flag set to true. If that transaction is successful, a profile is created. Then, theoretically, you could do the capture. The problem with this is that a transaction with createProfile set to true is basically just a one step version of "first do the transaction, then do createProfileFromTransaction". So, that initial transaction is still not associated with the profile. A second more immediate problem is that the createProfile flag currently doesn't work if a nonce is involved (although that should be fixed at some point).

None of these options are great, but at least option 1 would get you what you want, albeit with a couple of extra API calls.