Description
When using the ABP Payment module with MongoDB, the Plan entity is persisted to a collection named Plans instead of PayPlans. The PaymentDbProperties.DbTablePrefix (default: "Pay") is not applied to the Plans collection, even though it is correctly applied to PaymentRequests → PayPaymentRequests.
This contradicts the official documentation which states:
MongoDB Collections: PayPaymentRequests, PayPlans
Environment
- ABP Framework version: 10.1.0 (also reproduced on 10.0.0)
- Database provider: MongoDB
- Tiered/MVC or Blazor Server: Blazor Server
- OS: Windows 11
Steps to Reproduce
- Create a new ABP application with the Payment module and MongoDB provider
- Ensure
AbpPaymentMongoDbModuleis loaded (either standalone or viaReplaceDbContext<IPaymentMongoDbContext>()) - Call
modelBuilder.ConfigurePayment()inCreateModel()(as per documentation) - Navigate to Payment > Plans admin UI and create a new Plan
- Check MongoDB collections
Expected Behavior
Both collections should have the "Pay" prefix applied by ConfigurePayment():
| Entity | Expected Collection |
|--------|-------------------|
| PaymentRequest | PayPaymentRequests |
| Plan | PayPlans |
Actual Behavior
| Entity | Actual Collection | Prefix Applied? |
|--------|------------------|-----------------|
| PaymentRequest | PayPaymentRequests ✅ | Yes |
| Plan | Plans ❌ | No |
The Plan entity is created in a collection named Plans (without the "Pay" prefix), while PaymentRequest correctly uses PayPaymentRequests.
Investigation
PaymentDbProperties.DbTablePrefixreturns"Pay"(confirmed via IL metadata inspection ofVolo.Payment.Domain.dllv10.1.0)PaymentMongoDbContextExtensions.ConfigurePayment()has identical IL body size (199 bytes) in both v10.0.0 and v10.1.0, suggesting the bug exists in both versions- The
abppkg.analyze.jsonin both versions shows base collection namesPlansandPaymentRequests— the prefix is expected to be applied at runtime byConfigurePayment() IPaymentMongoDbContextexposes bothPlansandPaymentRequestsproperties, both callingCollection<T>()which should resolve the configured collection name
Workaround
Explicitly override the collection name for Plan (and PaymentRequest for safety) after calling ConfigurePayment():
protected override void CreateModel(IMongoModelBuilder modelBuilder)
{
base.CreateModel(modelBuilder);
modelBuilder.ConfigurePayment();
// Workaround: force "Pay" prefix on Payment entities
modelBuilder.Entity<Plan>(b =>
{
b.CollectionName = PaymentDbProperties.DbTablePrefix + "Plans";
});
modelBuilder.Entity<PaymentRequest>(b =>
{
b.CollectionName = PaymentDbProperties.DbTablePrefix + "PaymentRequests";
});
}
Impact
- Applications that rely on
ConfigurePayment()to set collection names will havePlanentities stored inPlansinstead ofPayPlans - This causes inconsistency with
PayPaymentRequestswhich is correctly prefixed - Custom repositories that hardcode
"PayPlans"(as documented) will fail to find data - The SaaS Edition > Plan lookup works because it reads from wherever ABP writes, but the collection name does not match the documentation
2 Answer(s)
-
0
- This is a known issue/bug in the Payment module’s MongoDB model mapping (reproducible in v10.0.0 and v10.1.0 as you observed): the
Planentity’s MongoDB collection name is not being configured withPaymentDbProperties.DbTablePrefix, so it falls back to the default convention and ends up asPlans, whilePaymentRequestcorrectly becomesPayPaymentRequests. - Workaround (recommended until fixed in a patch): keep your current override in your MongoDbContext’s
CreateModel(orOnModelCreatingequivalent for Mongo) and force the collection name forPlan(and optionallyPaymentRequest) after callingmodelBuilder.ConfigurePayment():
protected override void CreateModel(IMongoModelBuilder modelBuilder) { base.CreateModel(modelBuilder); modelBuilder.ConfigurePayment(); // Workaround: enforce prefix for collections that are incorrectly mapped modelBuilder.Entity<Volo.Payment.Plans.Plan>(b => { b.CollectionName = PaymentDbProperties.DbTablePrefix + "Plans"; }); // Optional safety (this one is already correct in your case) modelBuilder.Entity<Volo.Payment.PaymentRequests.PaymentRequest>(b => { b.CollectionName = PaymentDbProperties.DbTablePrefix + "PaymentRequests"; }); }Result: New writes will go into
PayPlansas documented (instead ofPlans). If you already have data inPlans, you’ll need to migrate/rename the existing collection in MongoDB (ABP won’t automatically move documents).If you want to keep the workaround minimal: only override
PlansincePaymentRequestis already correct in your environment.
Sources:
- https://abp.io/docs/latest/modules/payment
This response was generated by AI. If it didn’t solve your problem, feel free to post a new answer — our support team will jump in to help you soon.
- This is a known issue/bug in the Payment module’s MongoDB model mapping (reproducible in v10.0.0 and v10.1.0 as you observed): the
-
0
hi
I will fix it, your ticket has been refunded.
Thanks.